October 17th, 2024

Escaping the Chrome Sandbox Through DevTools

Two vulnerabilities in Chromium allow malicious extensions to escape the sandbox and execute commands on users' PCs. The author received a $20,000 reward for reporting these significant security risks.

Read original articleLink Icon
Escaping the Chrome Sandbox Through DevTools

This blog post discusses the discovery of two vulnerabilities, CVE-2024-6778 and CVE-2024-5836, in the Chromium web browser that allow a malicious Chrome extension to escape the browser's sandbox and execute shell commands on a user's PC. The author received a $20,000 reward from Google for reporting these vulnerabilities. The Chromium sandbox is designed to isolate untrusted code, limiting its access to the system. However, the author identified a flaw in the WebUI mechanism, specifically in the chrome://policy/test page, which was intended for testing enterprise policies. By exploiting an undocumented feature, the author was able to set arbitrary user policies without proper validation, effectively bypassing the sandbox. This vulnerability could allow an attacker to execute commands that could lead to full control over the operating system, rather than just stealing sensitive information. The author explains the technical details of how the exploit works, including the role of private APIs and the lack of necessary checks in the code. The findings highlight significant security risks associated with the Chrome browser's handling of enterprise policies and the potential for malicious extensions to exploit these weaknesses.

- Two critical vulnerabilities in Chromium allow sandbox escape via malicious extensions.

- The author received a $20,000 reward from Google for reporting the vulnerabilities.

- The exploit involves bypassing validation on the chrome://policy/test page.

- Attackers could execute arbitrary commands, compromising the entire operating system.

- The findings emphasize the need for improved security measures in Chromium's policy handling.

Link Icon 16 comments
By @bschne - 6 months
> You may have noticed that the page URL gets substituted into ${url}, and so to prevent this from messing up the command, we can simply put it behind a # which makes it a comment

Is there some validation logic or something on this policy that the URL must be passed to the "alternative browser" somewhere in the AlternativeBrowserParameters?

By @rs_rs_rs_rs_rs - 6 months
>I'm Allen, a high school student with an interest in programming, web development, and cybersecurity.

Very impressive!

By @AlexDragusin - 6 months
Excellent writeup and work, reading this made me be right there along with you in the excitement buildup thoughout the discoveries. Thank you!

Well deserved reward!

By @forkerenok - 6 months
That's a neat vulnerability chain and a great writeup. Appreciated the breakdown of the vulnerable code as well!

I'm always impressed by the simplicity of tricks like "Press F12 to try again", this is just so naughty :)

By @Sephr - 6 months
Reminds me of when I used this same API to debug Chrome OS's "crosh" shell and escape OS protections, also obtaining root access on developer devices. (CVE-2014-3172)

The author of this post had to bypass much more challenging obstacles. This is great work!

By @noduerme - 6 months
Oof. Too late in my night to dive into the guts of what's broken in WebUI validation, but good on this person for persisting and figuring it out. It's pretty standard to question and distrust toolchains in the things we deploy, but at the same time we put way too much trust in magically convenient dev tools from large companies like Google or MS. Mostly because we want to get on with writing and testing our own code, not worry about whatever the fuck is lurking in Chromium or VSCode.
By @purple-leafy - 6 months
God damn that is one of the best things I’ve ever read.

Super clever sleuthing

By @changexd - 6 months
Thanks for the writeup, very interesting and detailed! and the effort of digging through the browser code to find all this is fantastic!
By @igtztorrero - 6 months
Wow, wow and wow for a High school student.
By @est - 6 months
Chromium project decides to remove chrome://net-internals because the page is too complex

... and adding chrome://policy with half baked JSON edit support.

By @EDEdDNEdDYFaN - 6 months
really sick writeup, felt like a thriller novel
By @throwawayian - 6 months
Awesome vuln chain.
By @Etheryte - 6 months
Given the severity, I can't help but feel that this is underpaid at the scale Google is at. Chrome is so ubiquitous and vulnerabilities like these could hit hard. Last thing they need to do is to send the signal that it's better to sell these on the black market.
By @bossyTeacher - 6 months
Is it bad for Chrome to have vulnerabilities? I think long-term is really good. People need to get away from the browser monopoly (because it really is only Chrome here holding the power) and support the ecosystem