Web browsers are installed on billions of devices worldwide, making them prime targets for cybercriminals. Since major web browsers have massive user bases, a single vulnerability can have far-reaching consequences. Keeping browsers updated is critical for staying protected against evolving threats.
To illustrate the severity of vulnerabilities in web browsers, our fellows have conducted an extensive analysis of CVE-2024-6778, a vulnerability in Chromium-based browsers, particularly affecting Chrome DevTools. This blog provides a detailed examination of the vulnerability technical aspects, potential impact, and mitigation strategies.
Background of CVE-2024-6778
CVE-2024-6778 is a race condition vulnerability discovered in Chrome DevTools. It enables attackers to inject malicious HTML or JavaScript into privileged browser pages via malicious browser extensions. According to the NVD (National Vulnerability Database), this vulnerability has been rated with high severity, with a CVSS score of 8.8.
The high severity rating of this vulnerability is due to its potential to enable remote code execution, which can result in compromising systems, damaging confidentiality, and reducing availability.
Chromium Security Overview
To gain a deeper understanding of the implications of CVE-2024-6778, it is important to know about the key aspects of Chromium’s security model. Chromium is the open-source foundation for browsers such as Google Chrome, Microsoft Edge, Opera, and Brave. It employs a multi-process model where each tab, also referred to as a renderer, and various browser components run in isolated processes to enhance stability and security by limiting the scope of potential compromises.
A fundamental element of Chromium’s security is its sandboxing mechanism, which restricts renderer processes from directly accessing system resources. Instead, all interactions are managed through IPC (Inter-Process Communication) channels to ensure only authorized operations are performed.
Not all components within Chromium are subject to full sandboxing. WebUI pages, such as chrome://settings and chrome://downloads, are rendered within the renderer processes but operate with partial sandbox restrictions. This process grants them access to browser APIs that are typically not accessible via the web.
For instance, the chrome://policy page plays a vital role in enterprise environments since it enables administrators and users to configure and enforce browser security policies. These policies are also managed through Group Policy on Windows systems.
Because chrome://policy can interact directly with the operating system, it is a valuable target for attackers. With the CVE-2024-6778 vulnerability exploiting a race condition within Chrome DevTools, attackers can inject malicious code into these pages, posing serious security risks.
Technical Analysis of CVE-2024-6778
Discovery
This vulnerability was discovered in a test feature introduced in Chrome Enterprise version 117. This feature enables policy testing through the chrome://policy/test page. Due to limited official documentation on this feature, our fellows conducted a thorough examination of the Chromium source code, supplemented by insights from the CVE author, to fully understand its implementation and identify associated security vulnerabilities.
Policy Management Components
OPSWAT fellows’ source code analysis revealed that within chrome://policy/test, policies are managed using the PolicyInfo interface and communicated between the WebUI and browser processes through the PolicyTestBrowserProxy class. The PolicyInfo structure is defined as follows:
By further examination of the class responsible for handling these policies identified a method named applyTestPolicies. This method leverages a private API, setLocalTestPolicies, to dynamically apply a list of policies.
To gain insight into how policy requests are processed via this API, the fellows analyze the HandleSetLocalTestPolicies method within the PolicyUIHandler class:
The HandleSetLocalTestPolicies method retrieves the policy data from the provided arguments and obtains a pointer to the LocalTestPolicyProvider instance via the browser's global policy connector. Then, it verifies the existence of this provider before instructing the current user profile to utilize it.
This verification was found to be insufficient, as it only ensures that local_test_provider is non-null before applying the policies. The creation and initialization of local_test_provider are controlled by the CreateIfAllowed method:
Within the CreateIfAllowed method, the return value is entirely dependent on the result of the IsPolicyTestingEnabled function. This function determines whether a LocalTestPolicyProvider instance is created, based on a combination of user preferences and the browser’s release channel:
Since pref_service is consistently set to null each time IsPolicyTestingEnabled() is called, the first condition is bypassed, leaving the enablement decision relying solely on the browser’s release channel.
In unbranded Chromium builds, the release channel defaults to Channel::UNKNOWN. According to the function’s logic, Channel::UNKNOWN is treated the same as Channel::DEFAULT, which enables the policy testing feature by default. The code flow analysis revealed that the private API setLocalTestPolicies can be invoked via WebUI to apply policies without any meaningful access restrictions.
Exploitation
By identifying and leveraging this private API, an attacker can arbitrarily apply policies through the WebUI, enabling manipulation of settings such as BrowserSwitcherEnabled, BrowserSwitcherUrlList, AlternativeBrowserPath, and AlternativeBrowserParameters to execute commands. For example, by setting AlternativeBrowserPath to powershell and AlternativeBrowserParameters to ["calc"], arbitrary shell commands can be executed when a specific URL is visited.
Apply Arbitrary Malicious User Policy via Private API
To demonstrate how policies can be applied using the private setLocalTestPolicies API identified in the previous analysis, the following JavaScript code is a script that sets the AllowDinosaurEasterEgg policy and effectively applies it via the WebUI by invoking setLocalTestPolicies:
The policy can be successfully applied to disable the AllowDinosaurEasterEgg setting.
For greater impact, an attacker may target the BrowserSwitcher policy:
This policy enables the browser to invoke an alternative browser path if the URL matches certain conditions. It can be exploited by configuring this path to point to a system executable to execute operating system commands. The following JavaScript code demonstrates this approach:
This script does the following tasks:
- Enables the
BrowserSwitcherfeature for example.com - Sets the alternative browser path to powerShell
- Executes
calcwhenever the specified URL is accessed.
Malicious Chrome Extension Simulation
Identifying the private API that allows policies to be applied introduces a significant attack vector for adversaries. To effectively exploit this vulnerability, an attacker would need to develop a malicious Chrome extension that uses the Chrome DevTools API to execute malicious JavaScript code.
To demonstrate the potential real-world impact, our fellows simulated a scenario in which a malicious Chrome extension is installed on a vulnerable browser and used to execute the attack.The chrome.devtools APIs in Chrome Extensions enable developers to extend and interact with Chrome's DevTools interface.
However, executing the DevTools API through an extension presents certain challenges that must be bypassed. First, the DevTools API is only operational when DevTools is open and actively inspecting a website. Second, the DevTools API does not permit code execution on the web user interface, WebUI. This limitation helps maintain the security and integrity of the WebUI during development and inspection processes
Signs Indicating Javascript Execution via reload API
Further analysis revealed that the chrome.devtools.inspectedWindow.reload function lacks the verification to confirm whether an extension is permitted to run scripts on the inspected page. Its only level of defense is the devtools extension server, which blocks access once the inspected page’s URL changes.
About:blank pages inherit the permissions and origin of the page that opened them. This means that the ability to execute code on about:blank when redirected from the WebUI signals is a potential vulnerability.
Executing Code on webUI via reload API
The race condition in chrome.devtools.inspectedWindow.reload() allows code execution on Chrome's WebUI pages (e.g., chrome://policy), which are typically protected. The exploit takes advantage of the reload API's ability to inject JavaScript during page transitions. Here's how it works:
- Target webUI: Open a WebUI page (e.g., chrome://policy) in a tab and attach DevTools.
- Inject Script: Use the reload() API with an
injectedScriptparameter to run arbitrary JavaScript during the reload. - Exploit Race Condition: The race condition occurs when the reload triggers before the WebUI's security mechanisms fully initialize, allowing the injected script to execute.
In the context of navigating from the about:blank page to chrome://policy:
As only the URL is verified instead of the page's origin, a brief period exists after navigation where the origin reflects the new page while the URL remains unchanged.
If chrome.devtools.inspectedWindow.reload is invoked during this window, it may unintentionally execute JavaScript on the destination page.
Improving Reliability for Race Conditions
Exploiting the race condition is inherently unreliable due to its dependence on timing. Additionally, rapid reloads or malformed scripts can cause page crashes. A novel approach to improve reliability involves intentionally inducing a page crash, as commands issued via DevTools are typically canceled during a crash, but Page.reload mapped to chrome.devtools.inspectedWindow.reload() is whitelisted and executed after the page reloads.
The following is a workflow model to crash a page by pushing subsequent commands:
Debugger Statement in Content Script Can Trigger a Crash
Using the debugger twice in quick succession disrupts the navigation process in a content script. It can lead to a crash by placing navigation_commit_state_ into an unanticipated state. This issue arises when RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 is executed, altering _navigation_commit_state to an unexpected value.
The first invocation pauses execution, leaving navigation_commit_state_ in an inconsistent state, and the second pauses during the CHECK_EQ check, failing the state validation and causing a crash.
Remediation
Neglecting to regularly update your browser version can leave your device exposed to serious security threats, especially those tied to CVEs (Common Vulnerabilities and Exposures). To help mitigate this risk, MetaDefender Endpoint™ delivers robust protection by detecting your browser version and checking for vulnerabilities, including known CVEs like CVE-2024-6778.
MetaDefender Endpoint ensures your application is up to date and flags any outdated or infected versions. It also lists installed applications with known vulnerabilities, categorized by CVE severity, and recommends fixes to effectively mitigate potential threats. To see a live demo on how MetaDefender Endpoint can help you mitigate those risks, get in touch with one of our experts today.
