Constantly striving to enhance the security of browsing the web, the Chrome Security Team focuses on implementing measures to render certain security vulnerabilities infeasible, applying mitigations that complicate the exploitation of such vulnerabilities, and employing sandboxing to limit the potential impact of isolated security issues. When determining the areas to concentrate on, it is beneficial to examine how malicious entities discover and exploit vulnerabilities. This article delves into multiple aspects that can be used to assess the potential risks to users from exploits and how they link to the Chrome browser.

Throughout its history, the Chrome Security Team has made significant investments to promote web safety. It has been a pioneer in introducing browser sandboxing, site isolation, and the transition to an encrypted web. Presently, the focus is on adopting Rust for memory safety, strengthening the existing C++ codebase, and enhancing detection capabilities through GWP-asan and lightweight use-after-free (UAF) detection. The assessment of user harm and the utility of an attack play a significant role in shaping our vulnerability severity guidelines, as well as determining rewards under our Vulnerability Rewards Program. In the long run, the Chrome Security Team advocates for enhancements in the operating system, such as less-capable lightweight processes, less-privileged GPU and NPU containers, improved application isolation, and backing for hardware-based isolation, memory safety, and flow control enforcement.

When considering a specific security modification, one might easily fall into a state of security nihilism, tending to reject alterations that do not eliminate exploitation entirely but instead make it more arduous. Nevertheless, given the scale at which we operate, even incremental enhancements hold significance. Over time, across the user base of Chrome and Chromium-based browsers, these improvements collectively impose real obstacles for attackers.

Assessment Framework for Code Execution Vulnerabilities

Our utmost security objective is to ensure that clicking on links is safe, enabling individuals to confidently access previously unvisited web pages. While this document primarily addresses vulnerabilities and exploits linked to code execution, the same approach can be adopted when mitigating other risks.

Typically, attackers have a specific end goal that requires executing their code beyond Chrome’s sandboxed or restricted processes. Their objectives involve attaining information or capabilities not intended to be available to websites or extensions within the sandboxed renderer process. This could entail executing code as the user or with system privileges, reading other process memories, accessing credentials, or opening local files. Here, we concentrate on attackers commencing with JavaScript or the ability to transmit packets to Chrome and culminating in something valuable. Our discussion is confined to memory-safety issues, given their prominence in ongoing fortification endeavors.

User Damage ⇔ Attacker Effectiveness

Chrome Security is equipped to systematically diminish risks for users by limiting the maneuverability of attackers. Any measure that complicates or, ideally, precludes the realization of certain attacker objectives holds value. Users of Chrome face myriad adversaries; therefore, it is imperative not to singularly focus on a particular threat actor or targeted user, the most sophisticated and persistent attackers, or the most astute web users. Chrome’s security safeguards a diverse user base from an array of risks posed by various attackers. Concentrating on a solitary bug, vector, attacker, or user underestimates the scale at which both Chrome and its adversaries operate. By reducing risks or increasing hurdles for even a fraction of potential threat scenarios, someone, somewhere, gains a safer browsing experience.

While superior exploits exist for attackers, we must acknowledge and prioritize initiatives that effectively thwart or marginally decrease the accessibility or efficacy of the most potent bugs and escalation methods.

Effective Bugs vs. Ineffective Bugs

All bugs are detrimental, but certain bugs are more exploitable. High-value bugs and escalation techniques for attackers share some, if not all, of the following attributes:

An exploit that sporadically crashes or only permits exploitation in specific instances is less advantageous compared to one that can be consistently triggered. Crashes might lead to detection by either the target or defense entities tracking such incidents. Attackers may not have multiple opportunities to execute their attacks. Bugs requiring specific thread interactions or sequential actions demand greater resource utilization and time for triggering. In scenarios where attackers are willing to risk detection via a crash, they can repeatedly attempt their attacks due to Chrome’s use of a multi-process architecture for cross-domain iframes. Conversely, bugs that only manifest when the primary browser process terminates prove more challenging to exploit, affording attackers a singular opportunity per session.

Given that Chrome is designed for users to visit websites and navigate links, we establish minimal interaction as the baseline. Exploits contingent on user actions, even if foreseeable, pose higher risks to attackers. Such exploits necessitate the presence of bug-related code on the system for longer periods, carry lower success rates since the required actions may not always occur predictably, and are more conspicuous as users might become wary if seemingly executing unfamiliar actions.

A bug that manifests across multiple platforms and can be equally exploited on all of them is more advantageous than one limited to a single platform or necessitating adaptation for different platforms. Bugs prevalent on restricted hardware types or in narrower configurations only benefit attackers with specific targets utilizing such configurations. Integrating each bug into the exploitation process necessitates ongoing maintenance and testing efforts; hence, reducing the number of bugs required is preferable. While Chrome enjoys broad usage, with some of its libraries being even more extensively employed, attackers may invest extra resources in identifying and exploiting bugs within third-party code utilized by Chrome. Bugs reliant on extension installations or specific hardware setups offer limited utility compared to those accessible from any web page.

Attacks demanding significant time for setup or execution are less likely to succeed and more prone to detection. Developing a reliable exploit for a slow bug is more challenging due to the prolonged compile-test-debug cycles involved.

Bugs requiring exploitation techniques involving grooming or state manipulation for success aremore valuable in case the setting can be scripted. The closer the script is to the issue, the easier it becomes to regulate the scenario in which the issue will be triggered. Bugs located deep within a codec or a race within a thread that the attacker does not oversee are more challenging to script. Scriptable bugs can be smoothly incorporated into an exploitation flow, while non-scriptable bugs might only be beneficial if they can be merged with a related weird machine. Bugs situated next to a scripting engine like JavaScript are simpler to activate – heightening the severity of some bugs in third-party libraries in Chrome compared to other situations. Bugs within a closely linked API like WebGPU are simple to script. Chrome extensions can manage Chrome’s internal status and user-interface (for instance, they can open, close, and rearrange tabs), facilitating some user-interaction scripting.

Attackers require long-term assurance in their exploits and will wish to examine them against evolving versions of Chrome and the operating system supporting Chrome. Bugs that can be automatically duplicated in a test environment can be effortlessly assessed. Bugs that can solely be activated with user engagement, or after intricate network requests, or that demand interaction with third-party services are more challenging to test. They necessitate a complex test environment or a modified version of Chrome that emulates the environment in a manner that triggers the bug. Preserving this type of system consumes time and resources, rendering such bugs less appealing. Notably, the scriptability of a bug is linked to the bug’s surroundings. Scriptable environments are favorable for simpler testing.

Bugs that produce side effects that can be identified are less productive than those that function without notifying a user, adjusting system status, emitting events, or precipitating repeatable and detectable network traffic. Side effects encompass metrics, crashes or slowdowns, pop-ups & prompts, system logs, and artifacts like downloaded files. Side effects may not alarm a particular target of an attack as it occurs but might lead to the subsequent identification of targeted systems. A bug that multiple groups are aware of could be recognized without the attacker’s awareness, even if it appears successful.

Attackers will favor bugs that are improbable to be rectified or uncovered by others. Analyzing and integrating a bug into an exploitation suite likely includes significant initial work, and attackers will opt for bugs likely to persist for an extended period. Numerous attackers vend exploits as a subscription service, and their economic model might be disrupted if they need to discover bugs at a heightened rate. Bugs freshly introduced into a product or that might be found through widely recognized fuzzing techniques are liable to be found (and potentially fixed) more promptly.

Attackers will strive to safeguard their exploits from exposure and will select bugs that can be triggered only when they are assured they will exclusively be revealed to chosen targets. It is comparatively simple to distinguish a web user by using cookies, network intelligence, and features of the web platform. Eliminating categories of delivery mechanisms (e.g., no unencrypted HTTP) can complicate targeting every exploit.

Modern browsers do include several defenses that complicate exploiting some bugs or bug categories. Attackers generally must utilize the basics presented by a bug, then govern them to attain a sub-goal like executing arbitrary system calls. Some bugs may not chain smoothly to a subsequent stage, or might necessitate substantial integration effort or tools to permit a subsequent stage to proceed. The usefulness of some bugs is connected to how well they concatenate with later escalation or lateral movement mechanisms. Some bugs independently are not advantageous — but can be merged with other bugs to make them reliable or feasible. Numerous information leaks fall into this classification. A stable read-what-where primitive or a method to probe which memory is allocated simplifies an arbitrary write’s execution. If a definite escalation technique recurrently emerges in exploit chains or examples, it is worth evaluating if it can be rectified.

This may contradict intuition, but a bug that is simple to locate can be beneficial until Chrome pinpoints and amends it, and potential targets update. Chrome’s source code is publicly accessible, and attackers can search for recent security or stability fixes and exploit them until the fixes are distributed (N-days). Fuzzing captures the shallow bugs but does not target those with even basic state requirements that are still conducive to manual discovery. An attacker might elect to specialize in identifying bugs in a specific sector that typically does not receive much security concentration. Ultimately, attackers could implant the bug themselves in a library (a supply-chain attack).

Some bugs may be effortless to uncover for an attacker since they fabricated the bug, or challenging to unearth because they exist in an under-examined area of the code base or behind intricate state that is challenging to fuzz. This renders the bug, once discovered, more valuable as it is likely to persist longer since other actors are less inclined to stumble upon it. Attackers willing to reverse engineer and aim at closed-source Chrome components might access vulnerabilities that the broader security community is improbable to discover.

Attacker Goals & Economics

Some attackers adhere to a business model, while others operate within a budget framework. Broadly speaking, we concern ourselves with attackers desiring financial gain and those seeking to surveil individuals. Bugs and escalation mechanisms are worthwhile to either faction if they align with their operational methods. We can assess defenses against diverse attackers with varying economic structures. An unsophisticated actor targeting unsophisticated users might employ a broadly disseminated unreliable attack with a minimal return (e.g., persuading individuals to execute a malicious download). They solely need to succeed a small portion of the time. Other groups might conduct limited bug exploration but instead pick short-lived, previously corrected bugs and integrate them into exploit kits. Some attackers might be portrayed as possessing an infinite budget, yet they will still opt for the most economical and dependable mechanism to achieve their goals. The obsolescence of Flash and the subsequent shift to exploiting v8 possibly exemplifies this concept the best.

When implementing defenses or eliminating attack surfaces, we are essentially aiming to impede adversaries from realizing their objectives. Certain attackers might make alternative decisions if their operational economics undergo changes due to diminishing the profitability of the bugs supporting their operations. Some actors may be willing to allocate substantial resources to retaining a capability to target web users — and we can only speculate on their reaction to the modifications we introduce. For these advanced attackers, eradicating complete classes of vulnerabilities or escalation mechanisms will be more effective.

Avoid linear thinking

We perceive successful exploits as sequences — sequential phases that start with a bug, proceed through various escalation stages, and accomplish an attacker’s immediate objective of code execution or data access outside the sandboxed renderer process. We even request such sequences through our Vulnerability Rewards Programme. For instance, a JS type confusion allows for an out-of-bounds read/write in the v8 sandbox, a v8 sandbox escape bug allows read/write in the renderer, overriding a JIT write/execute region permits arbitraryThe execution of code and invoking system or browser APIs can result in a breakout from the browser sandbox. The intruder commences by delivering JavaScript to a Chrome user and eventually gains unrestricted code execution on the user’s device, probably to accomplish their higher-level objectives. Even effective defense strategies typically concentrate on specific pathways that trigger an incident (such as the lone arrow often depicted piercing fragments of swiss-cheese).

In truth, the landscape presented to potential attackers is a intricate network of hidden possibilities, some familiar to a few, and many still undiscovered. This surpasses the notion of ‘attackers think in graphs’, as we need to acknowledge that a defensive measure can be successful even if it does not deter every attacker from accessing all the individuals they intend to exploit.

Final Thoughts

It may be tempting to dismiss a strategy to mitigate or eliminate attack surfaces under the assumption that attackers can easily find alternative methods to accomplish their objectives. However, this perspective assumes the most advanced attackers and their most coveted targets. Our analysis should have a broader scope. We must understand that many attackers possess limited capabilities and expertise. Some might attach N-days to red team tools. Some may have a specialist or an exploit pipeline that functions effectively on a small portion of the Chrome codebase but require additional training or resources to identify useful vulnerabilities if their current area is restricted. Others may market exploit kits that require modifications if an escalation mechanism is eliminated. Previously dependable exploits might become less reliable or take longer. Creating challenges for attackers aids in safeguarding Chrome users.

While we advocate for not abandoning efforts on mitigations for escalation paths, it is evident that implementing measures that render it impossible or tough to exploit extensive categories of initial vulnerabilities or bypass a significant portion of mitigations is more crucial. Documented attacks usually begin with an initial vulnerability, making it enticing to channel all efforts there, but this overlooks beneficial interventions later in the attack chain. Declines in attacker efficiency result in increased costs for attackers and a reduction in overall risk.

Any mitigation or bug-reduction feature that impacts any of the utility axes mentioned above holds value for some Chrome users.

References

• Project Zero: Understanding a “positive” memory corruption vulnerability
• An Overview of Exploit Reliability & Understanding a “positive” Linux Kernel bug (Isosceles)
• Zero Day Markets with Mark Dowd (Security Cryptography Whatever podcast)
• Escaping the Sandbox (Chrome and Adobe Pdf Reader) on Windows, Zer0Con 2024, Zhiniang Peng, R4nger, Q4n
• Exploring Memory Safety in Critical Open Source Projects (CISA.gov)