Full Report
Jupyter Notebooks is an interactive computing platform while VS Code is a text editor. Somebody wrote an extension for Jupyter Notebooks to work with VS code. In the past, there was an XSS vulnerability in the handling of this but it wasn't used for anything too impactful. The goal of this post was taking that XSS to RCE. VS Code uses the electron framework, which is a variant of the Chrome browser, to run as a desktop application. Using the tool ElectroNG for basic auditing configurations, nodeIntegration for VSCode was turned on. This allows for JavaScript to have access to the runtime, giving code execution on the device with any XSS issue. The Jupyter Notebooks integration had a doubly nested iFrame when the content is loaded where the nodeIntegration is turned off; of course, this is where the XSS ocurred at. This iFrame sandboxes the user substantially but has the allow-same-origin flag on it. What does this mean? Files can be hosted on the same file system and it is considered the same origin. Because of the iFrame allowing access to the window as long as it's in the same domain (file system) we can access the top window. Since the top window has nodeIntegration turned on, accessing this window allows us to get code execution. So the new questions comes in: "how do we put something into this folder to bypass SOP on the iFrame?" It turns out that there is a parsing bug in the determining location of the file. Directory traversal can be used in order to trick the location of the file in the vscode-file handler to use a file on the domain that really shouldn't be used. Combining this with the XSS allows for the calling the top level domain, giving us code execution. The final hurdle is that we do not know the local directory of the user. However, this can be circumvented using the postMessage API given from VSCode to leak it. Additionally, the Workspace Trust feature is opted out of by this extension, making no further user interaction required. Even though the XSS bug was fixed, it was interesting to see how it was taken to code execution with the old bug. Electron can be very dangerous with complex systems like this one.
Analysis Summary
# Vulnerability: Escalation of Stored XSS to RCE in VS Code Jupyter Integration via iFrame Bypass
## CVE Details
- CVE ID: CVE-2021-26437
- CVSS Score: Not explicitly provided in the text (General severity is RCE, implying High/Critical)
- CWE: CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) combined with CWE-22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
## Affected Systems
- Products: Visual Studio Code (VS Code) with the Jupyter Notebook integration active.
- Versions: Versions prior to 1.59.1. (The original XSS was fixed in August 2021.)
- Configurations: The primary required configuration component is that the main VS Code window has `nodeIntegration: on` enabled (which is the default/used configuration for the main window). The vulnerability specifically exploits the fact that the Jupyter Notebook extension opts out of Workspace Trust protections.
## Vulnerability Description
The vulnerability chain begins with a pre-existing Cross-Site Scripting (XSS) flaw within the Jupyter Notebook rendering engine when loaded inside VS Code. This injection occurs in a doubly-nested, sandboxed `iFrame`. While the `sandbox` attribute limits privileges, the presence of the `allow-same-origin` flag meant that if the content loaded within the iFrame shared the same origin as the parent, it could access the parent window. Since the content is loaded via the `vscode-file` protocol (which treats the local file system paths as the "same origin"), the sandboxed content could access the top-level `Window`.
The critical escalation path leveraged two factors:
1. **iFrame Origin Bypass:** The `allow-same-origin` flag allowed bypassing the sandbox to reach the top window.
2. **RCE Primitive:** The top-level VS Code Electron `BrowserWindow` had `nodeIntegration: on`, granting JavaScript access to Node.js runtime functions (like `child_process.exec()`).
To connect the XSS (in the sandboxed iFrame) to the RCE (in the top window), an exploit pathway resembling **CVE-2021-43908** was used:
1. **Directory Traversal:** A parsing bug in the `vscode-file` handler allowed directory traversal (`..%2F..%2F`) to reference files outside the expected application folder structure.
2. **Path Leaking:** The attacker used the `postMessage` API to leak the current user's workspace directory path by tricking the system into sending the path back via a reply.
3. **Execution:** By combining the path traversal to load a malicious file *within the same local context* as the top window and using the leaked path information, the attacker could construct a payload to execute arbitrary code via the `top.require('child_process').exec()` call.
Crucially, since the Jupyter extension opts out of the **Workspace Trust** security feature, no further user interaction (like clicking "Trust Notebook") was required after opening the malicious `.ipynb` file.
## Exploitation
- Status: PoC available (The article describes assembling a Proof of Concept to achieve RCE).
- Complexity: Medium (Requires chaining an existing XSS with directory traversal techniques and postMessage API manipulation).
- Attack Vector: Local/Adjacent (Requires loading a malicious `.ipynb` file, likely from a malicious repository, into the VS Code environment).
## Impact
- Confidentiality: High (Ability to read arbitrary local files and leak path information).
- Integrity: High (Ability to execute arbitrary operating system commands).
- Availability: High (Potential for system damage or disruption via executed OS commands).
## Remediation
### Patches
- VS Code resolved the underlying issue in version **1.59.1**.
### Workarounds
- Ensure the **Workspace Trust** feature is fully enabled and respected by all installed extensions, especially those handling notebook rendering, to require explicit user consent before running untrusted code.
- Re-evaluating the configuration of Electron applications to disable `nodeIntegration: on` in windows that load untrusted content, or ensuring proper sandboxing is enforced via other security policies.
## Detection
- **Indicators of Compromise (IoCs):** Look for suspicious network connections originating from VS Code processes attempting to connect externally (if the RCE payload includes data exfiltration). Look for unexpected process execution originating from the VS Code process space (e.g., launching `calc.exe` or interacting with the file system in non-standard ways).
- **Detection Methods and Tools:** Use monitoring tools capable of tracing process execution originating from Electron/Chromium rendering processes. Security reviews of extensions to ensure they do not rely on legacy security models or opt-out of Workspace Trust.
## References
- Vendor Advisory: Reference to the fix being issued with VS Code 1.59.1.
- Relevant Link (Original XSS Advisory): hxxps://github.com/justinsteven/advisories/blob/master/2021_vscode_ipynb_xss_arbitrary_file_read.md
- Relevant Link (Similar Precedent): hxxps://blog.electrovolt.io/posts/vscode-rce/