Achilles' Heel of JS Engines: Exploiting Modern Browsers During WASM Execution

Achilles' Heel of JS Engines: Exploiting Modern Browsers During WASM Execution

Speakers: Unknown

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=X2JQrQQmOLA

Overview

This talk, "Achilles' Heel of JS Engines: Exploiting Modern Browsers During WASM Execution," delves into the evolving landscape of browser security, with a particular focus on vulnerabilities within WebAssembly (Wasm) execution. Presented by a group of researchers with a track record of discovering and exploiting bugs in major browsers like Chrome, Firefox, and Safari, the talk highlights a critical shift in the Wasm attack surface. While previous research often concentrated on compilation-related issues, the speakers argue that the Wasm execution phase, especially with the introduction of new proposals such as Wasm garbage collection (GC), now presents a fertile ground for highly exploitable vulnerabilities.

The core premise of the research is that the execution runtime of Wasm modules is significantly less tested and, consequently, less secure than its compilation counterpart or JavaScript execution environments. This gap in scrutiny, coupled with Wasm's low-level nature and fewer inherent safety checks compared to JavaScript, creates an environment ripe for exploitation. The talk underscores the importance of understanding these emerging attack vectors, particularly as Wasm continues to gain traction and integrate more deeply into modern web applications, making browser security an even more intricate challenge for both developers and defenders.

Background

▶ Watch: Introduction: Exploiting modern browsers during WASM execution (0:00)

WebAssembly, introduced in 2008, was designed as a low-level bytecode format for efficient execution in web browsers, enabling near-native performance for demanding applications. From its inception, security researchers have investigated its potential vulnerabilities. Historically, these vulnerabilities largely fell into two main categories: compilation issues and memory isolation flaws. Compilation issues typically involved errors in bad code parsing within the Wasm compiler, leading to failures or incorrect code generation. Memory isolation flaws, on the other hand, often manifested as out-of-bounds access when expanding memory or accessing JavaScript objects mystically from Wasm.

Over time, as research progressed and browser vendors implemented more robust security measures, many of these "old" attack surfaces have been significantly reduced. However, the WebAssembly ecosystem is not static. The past two years have seen the introduction of new proposals, such as Wasm garbage collection (GC), which fundamentally alter Wasm's runtime environment and introduce new complexities. These developments, while enhancing Wasm's capabilities, simultaneously create novel security challenges. The speakers emphasize that these new proposals are a primary driver behind the emergence of new vulnerability types.

A crucial distinction highlighted in the talk is the difference in security posture between Wasm and JavaScript. JavaScript, being a higher-level language with a more mature optimization pipeline, incorporates a greater number of security checks. Furthermore, JavaScript benefits from extensive fuzzing efforts, both internal to browser development teams and from external researchers, leading to the discovery and patching of numerous bugs. In contrast, Wasm is a low-level language that allows direct operation on the stack and registers. This low-level control comes with fewer inherent safety checks and vulnerability mitigations compared to JavaScript. This disparity, combined with a comparatively smaller volume of Wasm-specific fuzzing, means that the Wasm runtime, particularly its execution phase, represents a less explored and potentially more vulnerable attack surface. The speakers also referenced data from Salo at Google, indicating that many exploited V8 bugs in 2024 were Wasm-related, introduced in the past year, and some did not even require bypassing the V8 sandbox protection, reinforcing the criticality of this emerging threat.

Key Findings

▶ Watch: Two main types of WebAssembly security vulnerabilities (0:50)

The central and most significant finding presented in this talk is the identification of the Wasm execution phase as a newly prominent and highly exploitable attack surface within modern browsers. The researchers contend that while past security efforts largely focused on Wasm compilation, the execution runtime has remained comparatively "less tested." This oversight, they argue, has created a fertile ground for vulnerabilities that are often more severe and exploitable than their compilation-time counterparts.

Specifically, the talk points to several critical observations:

1. Shift to Execution Phase Vulnerabilities: The focus of Wasm security research needs to pivot from primarily compilation issues to the runtime execution environment. The execution phase, responsible for managing objects, memory, and stack frame switching, is less scrutinized, leading to a higher probability of undiscovered flaws.
2. Impact of New Wasm Proposals: The introduction of new Wasm features, such as Wasm garbage collection (GC), is directly contributing to the emergence of these new execution-phase vulnerabilities. These proposals introduce complex interactions and state management that can be mishandled, leading to security bypasses or memory corruption.
3. Increased Exploitability: The speakers classify vulnerabilities into two types: compilation bugs (leading to compilation failures) and execution issues (where the compiler generates incorrect but executable code). Their research confirms that execution issues are "generally more exploitable" than compilation vulnerabilities. This is because execution bugs can lead to arbitrary code execution or information leaks within the running process, often bypassing existing sandbox protections.
4. Evidence from Real-World Exploits: Analysis of recent V8 bugs exploited in 2024, as collected by Salo from Google, reinforces these findings. The data indicates that many of these Wasm-related bugs were introduced recently and, critically, some did not require bypassing the V8 sandbox, demonstrating the severity and direct impact of these execution-phase flaws. This suggests that the Wasm execution environment itself, rather than just its interaction with the sandbox, contains fundamental vulnerabilities.
5. Wasm's Low-Level Nature as a Double-Edged Sword: While Wasm's ability to operate directly on the stack and registers offers performance benefits, it also means it has fewer inherent safety checks and vulnerability mitigations compared to JavaScript. This low-level access, when combined with execution-phase bugs, can give attackers a powerful primitive for exploitation.

In essence, the key finding is a call to action for the security community: the "old module" of Wasm security needs a fresh perspective, with a concentrated effort on uncovering and mitigating vulnerabilities that arise during the dynamic execution of Wasm code, particularly those introduced by its evolving feature set.

Technical Deep Dive

▶ Watch: Why WASM is a target: Fewer security checks than JavaScript (1:45)

To understand the vulnerabilities discussed, it's essential to grasp the fundamental architecture of the Wasm virtual machine within a modern browser. The Wasm VM operates in two primary phases: compilation and execution.

The compilation phase is the initial stage where Wasm binary code, typically embedded within a JavaScript array and loaded via new WebAssembly.Module(), is processed. During this phase, the browser's Wasm engine parses the binary code and translates it into machine code or highly optimized machine code. This process involves various stages, including parsing, validation, and code generation, often leveraging just-in-time (JIT) compilers. Historically, many Wasm vulnerabilities were found here, related to malformed input or errors in the compiler's logic.

The execution phase is where the compiled Wasm code is actually run. This phase is represented by the lower part of the Wasm VM architecture. Once a Wasm module is compiled, an instance object is created, exporting Wasm functions that can then be invoked from JavaScript. A critical component of the execution phase, especially for performance, is On-Stack Replacement (OSR). OSR allows the browser's JIT compiler to dynamically replace currently executing, unoptimized code with a more optimized version when that code becomes "hot" (i.e., frequently executed). This dynamic replacement is a complex operation that involves transferring execution state between different code versions and is a known source of subtle bugs in JIT compilers, making it a prime target for security research in the Wasm context.

The speakers emphasize that the execution phase itself can be further divided into three sub-phases, though specific details about these sub-phases were not elaborated upon. What is critical, however, is that the code within these sub-phases, responsible for the actual runtime operations of Wasm, is "less tested." The runtime build provides crucial support for the execution of Wasm, including:

• Object Management: Handling Wasm-specific objects and their interaction with the host environment (e.g., JavaScript objects). New proposals like Wasm GC directly impact this, introducing new complexities in how objects are allocated, tracked, and deallocated.
• Memory Management: Managing Wasm's linear memory, including operations like memory expansion. Vulnerabilities here can lead to out-of-bounds reads/writes.
• Stack Frame Switching: Managing the call stack for Wasm functions and their interoperability with JavaScript calls. Errors in stack management can lead to control flow hijacking or information leaks.

Wasm's nature as a low-level language allows it to operate directly on the machine's stack and registers. While this provides performance benefits, it also means Wasm inherently has fewer safety checks and vulnerability mitigations compared to JavaScript. JavaScript, with its garbage collection and more abstract memory model, provides a higher level of isolation and type safety. The direct manipulation capabilities of Wasm, combined with potential flaws in the less-tested execution runtime, create a powerful primitive for attackers. For instance, an execution bug might allow an attacker to craft Wasm code that, when optimized by OSR or interacting with a newly introduced feature like Wasm GC, could bypass memory safety checks and achieve arbitrary memory read/write access. This could then be leveraged to achieve full arbitrary code execution within the browser's process, potentially without needing to escape the V8 sandbox. The analysis of recent V8 bugs, some of which did not require sandbox bypass, strongly supports the idea that the execution environment itself contains critical vulnerabilities.

Demo / Proof of Concept

▶ Watch: Focusing on exploitable 'execution issues' over 'compilation bugs' (2:30)

The talk focused primarily on identifying and characterizing the new attack surface within Wasm execution and did not detail a specific demo or proof of concept exploit. The researchers presented their methodology for analyzing recent vulnerabilities and identifying less-tested areas of the Wasm runtime rather than showcasing a working exploit.

Defensive Implications

▶ Watch: Identifying less-tested execution phase as the research target (4:00)

The findings presented in this talk carry significant implications for browser security and the development of secure web applications. Defenders, including browser vendors, web developers, and security researchers, must adapt their strategies to address the emerging threat landscape within Wasm execution.

1. Increased Scrutiny of Wasm Execution Runtime: Browser vendors must significantly increase their security auditing and fuzzing efforts specifically targeting the Wasm execution phase. This includes the runtime support for objects, memory, and stack frame switching, as well as complex interactions introduced by features like On-Stack Replacement (OSR). Existing fuzzers, often optimized for JavaScript or Wasm compilation, need to be enhanced or supplemented with tools designed to probe the intricacies of Wasm's runtime behavior.
2. Robust Security for New Wasm Proposals: The introduction of new Wasm features, such as Wasm garbage collection (GC), demands rigorous security analysis and testing before widespread deployment. These new proposals fundamentally alter Wasm's runtime model and introduce new attack surfaces. Developers and standards bodies should prioritize security reviews and threat modeling for these features to identify potential vulnerabilities early in their lifecycle.
3. Enhanced Memory Safety Checks: Given Wasm's low-level nature and direct access to stack and registers, it is crucial to ensure that all memory operations within the execution runtime are subject to stringent memory safety checks. This includes robust bounds checking for memory access, especially during dynamic memory expansion, and careful handling of Wasm's interaction with host JavaScript objects to prevent mystical access or type confusion.
4. Awareness of Execution vs. Compilation Bugs: Defenders should recognize that execution vulnerabilities are generally more exploitable than compilation failures. This means that even if Wasm code compiles successfully, it may still contain runtime flaws that can be leveraged for serious attacks. Defensive strategies should therefore extend beyond compilation-time validation to encompass runtime integrity checks and anomaly detection.
5. Developer Best Practices: While the talk primarily targets browser engine developers, web developers utilizing Wasm should be aware of these evolving threats. They should stay informed about browser security updates and consider the security implications of using advanced Wasm features. When possible, adhering to secure coding practices and minimizing the attack surface of Wasm modules can contribute to overall application security.
6. Continuous Security Research: The dynamic nature of Wasm development necessitates continuous security research. The community needs to identify new attack surfaces as Wasm evolves, develop new methodologies for finding execution-phase bugs, and collaborate with browser vendors to ensure timely patching and mitigation.

By focusing on these defensive measures, the security community can work towards shoring up the "Achilles' Heel" in modern browser engines and ensure that the performance benefits of WebAssembly do not come at the cost of user security.

Key Takeaways

• The Wasm execution phase has emerged as a critical and less-tested attack surface in modern browsers, shifting the focus from traditional Wasm compilation vulnerabilities.
• New Wasm proposals, particularly Wasm garbage collection (GC), are introducing complex interactions and novel issues that create significant security risks in the execution runtime.
• Execution vulnerabilities, where incorrect code can still execute, are generally more exploitable and severe than compilation failures, often bypassing existing sandbox protections.
• Wasm's low-level design, allowing direct stack and register operations, provides fewer inherent safety checks and vulnerability mitigations compared to JavaScript, making its execution environment a prime target for sophisticated exploits.
• There is an urgent need for increased fuzzing efforts and security research specifically targeting the Wasm execution runtime and its interactions with the browser's JavaScript engine.
• Browser vendors must prioritize robust security audits, enhanced memory safety checks, and proactive threat modeling for all new Wasm features to secure the evolving web platform.

About the Speaker(s)

The speakers are identified as a group of researchers deeply interested in browser security. They have a proven track record of finding and exploiting multiple bugs across major browser engines, including Chrome, Firefox, and Safari. Their expertise lies in dissecting complex browser architectures to uncover vulnerabilities, particularly in emerging web technologies like WebAssembly.