Full Report
All untrusted code in Chrome, especially JavaScript on websites and within browser extensions, runs in a Sandbox. Practically, this means that the code is limited to the set of APIs instead of system calls. The raw Chromium Gui, called WebUI with the chrome:// URL protocol, can interface with the raw C++ code and are privileged sections that run outside a sandbox. Being able to execute code within the chrome:// is usually game over with UXSS or some other bug. So, keeping this clean of malicious code is important to the security of the browser. With this knowledge, our story begins with looking at Enterprise Policies in Chromimum. These are a way for an administrator to enforce certain settings by devices owned by a school or company. These policies are downloaded remotely to a JSON file then placed in /etc/opt/chrome/polices for usage. Since it's annoying to write these policies by hand, the developers created a policy testing WebUI page at chome://policy. In particular, it shows a list of provided policies, logs them and allows for exportation. Oddly enough, you can't edit these policies. After some digging, they found an undocumented API for editing these. There is a feature check for whether it is possible to do this. Unfortantely, the check is faulty and always returns true for all builds of Chrome. At this point, we can only call the API from the privileged WebUI pages. Convincing somebody to copy JS into the console to execute is unlikely. So, how can we escalate this? Chrome extension sandbox escape! The previous vulnerability had been reported in the devtools Chrome extension APIs. When calling chrome.devtools.inspectedWindow.eval(), the command is stored. If the tab is crashed then moved to another page, since as a WebUI page, it gets executed! The key to this attack was sending a request to eval before Chrome decides to disable the devtools API but while you are on a WebUI page. Classic race condition! The author wondered if any variants of this vulnerability existed. They checked out the chrome.devtools.inspectedWindow.reload() function to try to do a similar thing. To the authors surprised, it worked! They could continually spam reload() requests with JavaScript and switch the tab to a WebUI page. This exploits a race condition between the communication of processes on killing the devtools API. Neat! What's the worst thing that we can do with the chrome://policy page? The enterprise policies have a setting for Legacy Browser Support called Browser Switcher. This is meant to launch an alternative browser when a user visits specific URLs in Chrome that are not supported. In particular, the AlternativeBrowserPath can be used to execute an arbitrary command with arbitrary commands. This gives us a shell if we can execute it! At this point, they have a shell but the race condition only works like 70% of the time with only a single chance to hit it. They were curious if the same revival trick from the original bug report would work. To their surprise, calling the debugger twice in a row results in a crash. At this point, the code is stored and will be launched upon recovery. However, it's at this point that we update the tab itself to a different location. Now, this is 100% reliable. So, what's the fix? Funnily enough, Google had fixed this vulnerability originally then added a special case that exempted reload() from this patch. Originally, they just cleared all pending messages unless it was a reload. Adding a loaderId on the renderer side. Ensures that a pending command is only valid on a single page. Fix the feature flag for test policies. Prevent the crash from happening in devtools. Idk how they did this though I absolutely love this blog post. The bugs are not super complex, they have simple to understand code snippets yet it's still high impact. To me, this really shows up complexity opens up the attack surface is crazy ways.
Analysis Summary
# Vulnerability: Chrome Sandbox Escape via DevTools and Policy WebUI
## CVE Details
- **CVE ID:** CVE-2024-5836 (Race Condition), CVE-2024-6778 (Crash-based Persistence)
- **CVSS Score:** 8.8 (High)
- **CWE:** CWE-362 (Race Condition), CWE-617 (Reachable Assertion/Crash-induced Persistence)
## Affected Systems
- **Products:** Google Chrome, Chromium-based browsers.
- **Versions:** Affected versions prior to the patches in mid-2024; research indicates the `reload()` flaw dates back as far as Chrome v45.
- **Configurations:** Systems where a malicious or compromised Chrome extension is installed with `devtools` permissions.
## Vulnerability Description
This vulnerability chain allows a Chrome extension to escape the sandbox and execute arbitrary shell commands on the host OS. The exploit leverages three primary flaws:
1. **Undocumented Privileged API:** The `chrome://policy` WebUI contained an undocumented "Policy Test" API intended for developers. A faulty feature check meant this API was active in production builds, allowing the modification of enterprise policies if Javascript could be executed in the `chrome://` context.
2. **DevTools Race Condition (CVE-2024-5836):** Extensions using `chrome.devtools.inspectedWindow.reload()` could bypass security boundaries. By spamming reload requests while navigating a tab to a privileged `chrome://` URL, a race condition occurs where the browser fails to revoke DevTools API access before the script executes in the privileged context.
3. **Crash-Induced Persistence (CVE-2024-6778):** By calling the debugger twice to force a renderer crash, an attacker can store malicious code in the "pending messages" queue. When the tab is recovered/reloaded at a privileged URL, the stored code executes with 100% reliability, bypassing the timing constraints of the race condition.
## Exploitation
- **Status:** PoC available; reported via Chrome VRP.
- **Complexity:** Medium (requires specific API calls and timing, but logic is straightforward).
- **Attack Vector:** Local (via a malicious Chrome extension).
## Impact
- **Confidentiality:** High (Full access to system files and user data).
- **Integrity:** High (Ability to execute arbitrary shell commands and install malware).
- **Availability:** High (Ability to crash the browser or modify system settings).
## Remediation
### Patches
Google has released several patches to address the chain:
- **DevTools Fix:** Added a `loaderId` on the renderer side to ensure pending commands are only valid for the specific page instance they were intended for.
- **Policy Fix:** Corrected the feature flag check for the "Policy Test" page to ensure it is disabled in production builds.
- **API Revocation:** Improved the teardown of DevTools API access during cross-process navigations.
### Workarounds
- Limit the installation of Chrome extensions to those from trusted developers.
- Use Enterprise "Extension Install Blocklist" to prevent unapproved extensions from running in sensitive environments.
## Detection
- **Indicators of Compromise:** Unexpected modifications to `/etc/opt/chrome/policies` (Linux) or registry keys (Windows) related to `BrowserSwitcher` or `AlternativeBrowserPath`.
- **Detection Methods:** Monitor for Chrome child processes spawning unusual shells or administrative tools (e.g., `cmd.exe`, `/bin/sh`) particularly initiated by the browser process.
## References
- **Vendor Advisory:** [https://chromereleases.googleblog.com/search/label/Stable%20updates]
- **Original Research:** [https://ading.dev/blog/posts/chrome_sandbox_escape.html]
- **PoC Repository:** [https://github.com/ading2210/CVE-2024-6778-POC]
- **Issue Tracker:** [https://issues.chromium.org/issues/338248595]