Enhanced Insecurity Mode: 23 RCEs in Edge's "Safe" WebAssembly Interpreter

Enhanced Insecurity Mode: 23 RCEs in Edge's "Safe" WebAssembly Interpreter

Speakers: Nan Wang (sakura) (Security Researcher, Cyber Kunlun); Ziling Chen (R1nd0) (Security Researcher, Cyber Kunlun)

Conference: OffensiveCon

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

Overview

In a groundbreaking presentation at OffensiveCon, Nan Wang (sakura) and Ziling Chen (R1nd0) from Cyber Kunlun unveiled a comprehensive analysis of Microsoft Edge's "Enhanced Security Mode," revealing 23 Remote Code Execution (RCE) vulnerabilities within its WebAssembly interpreter, Dropbear. This research highlights a critical paradox: a security feature designed to protect users by disabling Just-In-Time (JIT) compilation inadvertently introduced a significant new attack surface. The talk meticulously detailed how a pure software interpreter, intended to run WebAssembly in a hardened environment, became a fertile ground for high-impact security flaws.

The speakers, renowned for their expertise in browser security and consistently ranked among the top Chrome VRP researchers, presented a deep dive into Dropbear's internal architecture, its unique dual-stack design, and the intricate ways these design choices led to numerous vulnerabilities. Their findings, which alone would place them ninth on the Microsoft Security Response Center (MSRC) leaderboard, underscore the immense challenge of building secure, high-performance interpreters for complex web technologies like WebAssembly. The research serves as a stark reminder that new security mechanisms, while well-intentioned, require exhaustive scrutiny to ensure they don't introduce unforeseen weaknesses.

This presentation is not merely a collection of individual bugs; it's a profound exploration into the systemic issues that arise when fundamental architectural changes are made to a critical component like a WebAssembly runtime. By meticulously detailing their fuzzing methodology, three representative vulnerabilities, four additional bug classes, and a universal exploitation chain, Wang and Chen provided invaluable insights for both offensive and defensive security communities. Their work emphasizes the ongoing arms race in browser security and the continuous need for rigorous security review and fuzzing for any component handling untrusted input.

Background

▶ Watch: Introduction: 23 RCEs in Edge's Dropbear interpreter (0:00)

Microsoft Edge's Enhanced Security Mode is a crucial security feature designed to harden the browser's renderer process when visiting untrusted sites. Its primary mechanism involves disabling the V8 JIT compilers, thereby preventing the generation of Read-Write-Execute (RWX) memory pages. This, in turn, allows the activation of three powerful OS-level protections: Arbitrary Code Guard (ACG), Control-Flow Guard (CFG), and Hardware-Enforced Stack Protection (CET), which significantly raise the bar for exploitation.

However, disabling JIT compilation presents a fundamental challenge for WebAssembly (Wasm). V8's standard execution path for Wasm typically involves compiling it to native machine code, a process that inherently relies on JIT capabilities. Without JIT, Wasm execution would be severely hampered or entirely impossible. Microsoft's solution to this dilemma was to introduce Dropbear, a pure software interpreter integrated within TurboFan, V8's optimizing compiler. Dropbear's role is to execute WebAssembly bytecode without generating any machine code, thus bypassing the need for RWX memory and allowing Enhanced Security Mode to function with Wasm. Despite its critical role in maintaining security in a hardened environment, Dropbear had received very little public security scrutiny prior to this research.

In a normal V8 execution environment, WebAssembly functions are typically processed through a two-tiered compilation pipeline. Initially, functions are compiled by Liftoff, a baseline compiler that performs a single pass, maps the Wasm stack to CPU registers, and directly emits native instructions without intermediate representation (IR) or extensive optimizations. For hot functions, execution then tiers up to TurboFan, the optimizing compiler, which constructs an IR graph, applies sophisticated optimization passes, and generates highly optimized, faster native code. Both Liftoff and TurboFan ultimately produce native machine code that resides in RWX memory pages. In Enhanced Security Mode, ACG actively blocks these RWX pages, rendering both Liftoff and the compiling aspects of TurboFan unusable for Wasm. This is where Dropbear steps in: it decodes the WebAssembly into an internal bytecode format and interprets it through a dispatch loop, entirely in software.

A critical concept for understanding Dropbear's vulnerabilities is its dual-stack design. This design was implemented to support the WebAssembly GC proposal, which introduces managed heap objects such as structs, arrays, and function references. These objects are subject to V8's garbage collection (GC) mechanism and must be properly tracked to prevent memory safety issues. To accommodate this, Dropbear maintains two entirely separate stacks:

• The Value Stack: This stack stores primitive types like I32, I64, float, double, and SIMD values. It is implemented as a raw byte array, with its position tracked by a uint32 stack pointer (SP).
• The Reference Stack: This stack stores GC-managed objects, including wasm_struct, wasm_array, and function references. It is implemented as a V8 fixed array located on the managed heap.

The dual-stack design is crucial because if raw object pointers were stored directly on the value stack, the GC would be unaware of their existence and could potentially collect them while still in use, leading to dangling pointers and use-after-free (UAF) vulnerabilities. To prevent this, when a reference type is encountered, Dropbear writes a placeholder "depth" value on the value stack and stores the actual GC-managed object on the reference stack.

The reference stack is also carefully partitioned across function calls. Each function call receives its own segment, with its origin tracked by reference_array_current_SP, which effectively acts as a frame pointer for the reference stack. When a function is called, this offset is advanced to allocate a dedicated section for the callee. Upon function return, the offset is restored to the caller's frame. Any reference operation computes its absolute position by adding a local index to reference_array_current_SP. A misalignment or error in this calculation can cause references to land at incorrect positions, leading directly to type confusion.

Dropbear dispatches instructions using a function pointer table called KInstructionTable. Each instruction handler is responsible for reading its operands, performing its designated work, and then invoking the NextOp macro. The NextOp macro reads the ID of the next instruction from the bytecode, looks it up in KInstructionTable, and then tail calls the corresponding handler. This means that the current handler does not retain its stack frame; instead, it directly jumps to the next handler. This chain of tail calls is the fundamental mechanism by which Dropbear interprets the WebAssembly bytecode. A critical implication of this design is that every handler calls NextOp at its conclusion, and NextOp will dispatch whatever instruction the code pointer points to. If the code pointer becomes corrupted or is not correctly redirected, NextOp will execute unintended instructions, potentially leading to arbitrary code execution or other severe security flaws.

Key Findings

▶ Watch: Dropbear's critical dual stack design explained (4:00)

The core finding of this research is the discovery of 23 Remote Code Execution (RCE) vulnerabilities in Dropbear, Microsoft Edge's WebAssembly interpreter operating within Enhanced Security Mode. This extensive collection of vulnerabilities fundamentally undermines the "enhanced security" promise of the mode, demonstrating that a feature designed to protect users can introduce a significant new attack surface if its underlying components are not rigorously secured.

The researchers highlighted that Dropbear, despite playing a critical security role by enabling WebAssembly execution in a hardened environment, had received remarkably little attention from the security community prior to their work. This lack of scrutiny allowed numerous, fundamental flaws to persist.

A significant takeaway is that the types of bugs found are not novel or exotic. Instead, they fall into well-known categories of memory safety issues: type confusion, index errors, stale state, missing write barriers, and integer overflows. The recurrence of these classic vulnerability patterns in a new, complex codebase like Dropbear underscores the inherent difficulty in developing secure interpreters, especially those dealing with intricate concepts like WebAssembly's garbage collection and dual-stack architecture. The dual-stack design, in particular, requires maintaining a multitude of invariants across hundreds of instruction handlers, making it highly susceptible to these types of errors.

Crucially, the researchers were able to demonstrate a universal exploitation chain that leverages these type confusion primitives to achieve arbitrary read/write capabilities, ultimately leading to RCE. This consistency in exploitation paths across diverse bugs significantly increases the impact of each individual vulnerability. Microsoft responded swiftly to the disclosures, patching every reported bug, and the MSRC team was commended for their professional handling of the responsible disclosure process. This research serves as a powerful testament to the necessity of continuous, proactive security review and fuzzing for any new or existing interpreter that processes untrusted input, regardless of its intended security posture.

Technical Deep Dive

▶ Watch: Instruction dispatch mechanism via tail calls (next_off) (6:00)

The researchers employed a sophisticated fuzzing methodology to uncover the myriad vulnerabilities in Dropbear. Their approach leveraged V8's own random WebAssembly module generator, a tool Google itself uses for internal fuzzing. This generator takes random bytes as input and produces a valid Wasm module. The generation process consists of two phases:

1. Module Generation (ModuleGen): Reads random bytes to determine the overall structure of the Wasm module, including the number and types of functions, structs, and arrays.
2. Body Generation (BodyGen): Consumes additional random bytes to populate each function body with instructions, selecting from control flow constructs (blocks, loops), GC operations (e.g., struct.new, array.new), branches (br_on_null), and calls (return_call_ref).

While the random bytes dictate the generated instructions, the generator is designed to always produce output that passes the Wasm validator, ensuring syntactically and semantically valid modules. However, Dropbear only supports a subset of all Wasm features. To prevent "fatal" crashes on unsupported opcodes (which are not security bugs but wasted fuzzing time), the researchers patched the generator. Key modifications included disabling string operands, handling shared structs and custom descriptors, limiting generation to a single memory, and significantly increasing the maximum input size from 512 bytes to 500 kilobytes to enable the creation of more complex GC type combinations.

The complete fuzzing pipeline involved AFL (American Fuzzy Lop) feeding random bytes into the patched generator, which then produced valid Wasm modules. These modules were executed by D8, the V8 developer shell, with the --jitless flag enabled, ensuring that all WebAssembly code was processed exclusively through Dropbear. The build was configured with debugger assertions turned on to convert silent memory corruptions into visible crashes, making them detectable by AFL. AFL then collected coverage feedback and mutated inputs accordingly, optimizing the discovery process. This setup found the majority of the bugs, with subsequent variant analysis and pattern matching on the fuzzer's leads revealing the remaining vulnerabilities.

Vulnerability 1: Missing Return (S2S Return Call Ref)

This vulnerability, designated as S2S_ReturnCallRef, centers on an incorrect handling of tail calls within Dropbear. The WebAssembly specification for return_call_ref states two critical points:

1. It is a tail call: the current function effectively ends, and the callee runs in its place. Any code following return_call_ref is considered unreachable and should never be executed by the runtime.
2. It is stack polymorphic: the validator enters a special mode for instructions like return_call_ref, where it temporarily stops enforcing type checks on the stack. This is deemed safe because the subsequent code is unreachable.

A Wasm block declares a result type at its start, and the validator normally verifies that the value on top of the stack matches this type when the block ends. In stack polymorphic mode, this check is bypassed. If the runtime fails to uphold the promise of unreachable code, this bypass becomes a critical flaw, allowing the block's declared type to be arbitrarily mismatched with the actual value on the stack, leading to type confusion.

The bug in Dropbear's S2S_ReturnCallRef handler was that it called unwind_current_stack_frame and then execute_call_ref to run the callee. After execute_call_ref returned, the handler proceeded to call NextOp. The critical oversight was that execute_call_ref did not redirect the code pointer. Consequently, when NextOp was invoked, the code pointer still pointed to the unreachable instructions immediately following return_call_ref in the original bytecode. These instructions were then dispatched and executed as if they were legitimate code.

Exploitation: By exploiting the validator's stack polymorphic mode, an attacker could define a block that declared a struct as its result type, but func1 (the tail-called function) would actually return an array. Because the validator wasn't checking types in this "unreachable" region, the interpreter would treat a 12-byte wasm_array as a 400-byte wasm_struct. A subsequent StructSetField 15 operation, intended for the (non-existent) 15th field of the struct, would write far past the actual 12-byte boundary of the array. This out-of-bounds (OOB) write could then overwrite the array's length field, setting it to -1 (or a very large unsigned value), effectively granting arbitrary read/write access from JavaScript.

Fix: The fix was implemented within execute_call_ref, a runtime function called by the handler. After the tail call completed, execute_call_ref was modified to check if it was indeed a tail call. If so, it would call RedirectToUnwindHandler, which explicitly rewrites the code pointer to point to the S2S_Unwind instruction. This instruction simply halts the dispatch chain, ensuring that the unreachable code is never executed.

Vulnerability 2: Null Reference That Wouldn't Live (BR_ON_NULL)

This vulnerability concerns the br_on_null instruction, whose semantics are straightforward: pop a reference from the stack. If it's not null, push it back and take the branch. If it is null, drop it (consume it) and continue to the next instruction. Dropbear's implementation, however, failed to correctly drop the null reference.

The issue stemmed from a mismatch between Dropbear's runtime handler and its bytecode generator. The runtime handler for br_on_null was designed to peek at the reference (pop it, then immediately push it back) before checking for null. This design meant the handler always expected "someone else's job to drop the null afterward." That "someone else" was supposed to be the bytecode generator, which compiles Wasm instructions into Dropbear's internal operands. For br_on_null, the generator was expected to emit the handler to peek and branch, followed by a RefPop instruction to explicitly drop the null reference if the branch was not taken.

The Bug: The bytecode generator, specifically in its branches for br_on_null with with_signature and with_params, emitted the handler and set up the branch offset, but critically failed to emit the RefPop instruction afterward. Consequently, if the branch was not taken (i.e., the reference was null), the null reference remained on the stack.

Result: This left an extra null reference on the stack, causing a stack mis-alignment. Every subsequent stack operand would read from the wrong slot. This mis-alignment could be used to confuse a wasm_struct with a wasm_array, similar to the previous bug. For example, a Drop instruction, intended to remove a specific value, would instead remove the leaked null reference, further corrupting the stack state and leading to type confusion.

Fix and Patch Bypass (CVE): Microsoft's initial fix involved adding RefPop to the with_param pass of the bytecode generator. However, the generator had a separate pass for void signatures of br_on_null, which was overlooked. This void pass still lacked the RefPop instruction, allowing the null reference to continue leaking onto the stack. The researchers reported this as a CVE (Common Vulnerabilities and Exposures), highlighting a patch bypass.

Vulnerability 3: Counting Twice (Reference Stack Index Calculation)

This vulnerability involved an arithmetic error in the calculation of reference stack indices, leading to an incorrect memory write. At the core of the issue was the StoreWebAssemblyRef function, which is responsible for storing a reference onto the reference stack. This function takes a ref_stack_index (a local index within the current function's frame) and adds frame_ref_array_current_SP (the base offset of the current function's frame on the reference stack) to compute the absolute position where the reference should be stored. The arithmetic is simple: absolute_index = local_index + frame_offset.

The Bug: The problem arose because the caller of StoreWebAssemblyRef also added ref_array_current_SP to the ref_stack_SP_offset before passing it as an argument. As a result, the frame offset was effectively counted twice. For example, if ref_array_current_SP was 5 and the local_offset was 2, the intended absolute index would be 5 + 2 = 7. However, due to the double counting, the actual computation became 5 + 5 + 2 = 12.

Result: The reference was stored at position 12 instead of the intended position 7. The old value at position 7 remained unchanged. Later, when the interpreter attempted to read the return value from position 7, it would retrieve the stale, incorrect object, leading to another instance of type confusion.

Exploitation: This displacement could be engineered into type confusion by using two WebAssembly instances. One instance could export a function that returns a wasm_struct, while another instance imports and indirectly calls this function (call_indirect). The double counting would then cause the returned struct to be misinterpreted, leading to the same OOB read/write primitive.

Fix: The fix for this bug was straightforward: modify the caller to pass ref_stack_SP_offset directly, without pre-adding ref_array_current_SP, allowing StoreWebAssemblyRef to perform the addition only once internally.

Four Additional Bug Classes

Beyond these detailed examples, the researchers uncovered several other categories of vulnerabilities:

1. Stale State Bug: The PrepareTailCall function, responsible for setting up a tail call, correctly updated the current_function to the new target but failed to reset the call_exceptions_array. This array is sized based on the old function's block count. If the new function subsequently threw an exception with a larger block index, the SetCallExceptions function would attempt to write past the bounds of the old, undersized array, resulting in an OOB write into nearby heap memory.
2. Compile Time Bug in the Bytecode Generator: The RestoreIfElseParents function in the bytecode generator incorrectly called SetSlotType before UpdateStack. This meant that type information was written to the wrong stack slot, corrupting the compiler's internal stack tracking. Consequently, type checks would always succeed, allowing a wasm_struct to pass through a cast that was specifically intended for a wasm_array, leading to type confusion.
3. Missing Garbage Collector Write Barrier: Array and struct copy operations within Dropbear used raw memory copy functions (memcpy) instead of the StoreRefIntoMemory helper. This bypassed V8's write barrier mechanism, which is essential for informing the GC about changes to object references, particularly when moving objects from the "young generation" to the "old generation" heap. As a result, the remembered set (a list of objects that might contain pointers to younger objects) was not updated. This allowed the GC to incorrectly collect a still-referenced young generation object, creating a dangling pointer and leading to a use-after-free (UAF) vulnerability.
4. Classical Integer Overflow: The ArrayCopyChecks function, which validates array copy operations, calculated offset + size using uint32 arithmetic. For sufficiently large values, this addition would wrap around, causing the result to be smaller than expected and pass the bounds check. However, the subsequent memmove operation, which performed the actual copy, used the unwrapped, much larger size. This discrepancy led to an enormous OOB write, potentially over 4 billion bytes, corrupting a vast region of memory.

Demo / Proof of Concept

▶ Watch: Complete fuzzing pipeline and bug discovery process (9:00)

The talk demonstrated a powerful and universal exploitation chain that could leverage most of the discovered type confusion vulnerabilities to achieve Remote Code Execution (RCE). The key insight underpinning this chain is the remarkably similar heap layouts of wasm_struct and wasm_array objects within V8. Both types begin with a map pointer at offset zero, which defines their type and properties. However, their subsequent fields diverge critically: in a wasm_array, the next field is length, while in a wasm_struct, it is field_zero (the first user-controlled data field).

This structural similarity is the linchpin of the exploitation chain:

1. Type Confusion Primitive: The first step involves triggering any of the type confusion vulnerabilities discussed (e.g., S2S_ReturnCallRef bug, br_on_null stack misalignment, or counting twice error). When Dropbear incorrectly treats a wasm_struct as a wasm_array, the struct.field_zero becomes interpreted as the array.length.
2. Out-of-Bounds Read/Write within V8 Heap: Since field_zero is user-controlled data, the attacker can set it to an arbitrarily large value (e.g., approximately 2 billion). This manipulates the perceived length of the wasm_array. Subsequent array.get and array.set operations, now believing the array has billions of elements, can read and write far past the actual allocated memory boundary. This grants the attacker an out-of-bounds (OOB) read/write primitive anywhere within the V8 managed heap.
3. Corrupt JavaScript Array Length: To elevate this heap primitive to a more powerful capability, the attacker calls a JavaScript import function from WebAssembly to allocate a JavaScript array. Using the newly acquired OOB write primitive, the attacker then corrupts the length field of this newly allocated JavaScript array to an extremely large value.
4. Arbitrary Read/Write from JavaScript to RCE: From within JavaScript, the now-corrupted JS array effectively has unlimited bounds. This provides the attacker with an arbitrary read/write primitive that can be directly controlled from JavaScript. From this point, standard V8 exploitation techniques can be employed to achieve full RCE, typically involving locating and overwriting critical function pointers or re-purposing existing code gadgets.

This four-step chain highlights the severe impact of type confusion bugs in interpreters, demonstrating a reliable pathway from a logical flaw to full system compromise.

Defensive Implications

▶ Watch: First vulnerability: The missing return (tail call bug) (10:00)

The research into Dropbear's vulnerabilities carries significant defensive implications for developers, security engineers, and browser vendors. The primary takeaway is that any new interpreter handling untrusted input requires rigorous security review and extensive fuzzing from day one. The case of Dropbear, a component introduced to enhance security, yet riddled with vulnerabilities, serves as a potent reminder that security features themselves can introduce new attack surfaces if not developed and audited with extreme care.

The complexity of WebAssembly, particularly with features like the GC proposal and the intricacies of a dual-stack architecture, makes interpreter development inherently challenging. The need to maintain numerous invariants across potentially hundreds of instruction handlers creates a fertile ground for subtle errors that can lead to severe security flaws. Defenders should recognize that the design choices made at an architectural level can have profound security consequences down the line.

The recurrence of well-known bug patterns—type confusion, index errors, stale state, missing write barriers, and integer overflows—is a critical observation. This indicates that even with decades of experience in software security, these fundamental classes of vulnerabilities continue to manifest in new, complex, and performance-critical codebases. Developers must not assume that established bug patterns are no longer relevant; rather, they should be hyper-vigilant in identifying and mitigating them in any new code. Implementing robust sanitization, bounds checking, and strict type enforcement, even in performance-sensitive paths, is paramount.

The success of the fuzzing methodology, leveraging V8's own module generator and AFL with coverage feedback, underscores the effectiveness of intelligent fuzzing strategies. Defenders should invest in similar advanced fuzzing capabilities for their own critical components, tailoring generators to the specific semantics and features of the target system. Building with debugger assertions enabled during fuzzing is also crucial, as it transforms silent memory corruptions into detectable crashes, providing invaluable feedback for bug discovery.

Finally, the prompt and professional response from Microsoft, patching all 23 CVEs quickly, demonstrates the importance of a mature vulnerability disclosure and patching process. This collaboration between security researchers and vendors is essential for improving the overall security posture of complex software like web browsers. Organizations should foster environments where security researchers can responsibly disclose vulnerabilities, leading to swift remediation and enhanced user protection.

Key Takeaways

• Microsoft Edge's Enhanced Security Mode, while aiming to disable JIT for security, introduced Dropbear, a new and vulnerable WebAssembly interpreter that became a significant attack surface.
• Developing secure WebAssembly interpreters, especially those incorporating complex features like garbage collection and dual-stack architectures, is an extremely challenging task prone to subtle errors.
• Common vulnerability patterns, including type confusion, out-of-bounds access, integer overflows, use-after-free, and stale state, continue to appear in new, complex interpreter implementations.
• Effective fuzzing strategies, such as patching official module generators and using coverage-guided fuzzers like AFL with debugger assertions, are crucial for discovering deep, architectural bugs in interpreters.
• A universal exploitation chain, leveraging type confusion to manipulate object lengths and achieve arbitrary read/write, consistently leads to Remote Code Execution (RCE) in V8-based environments.
• Any new software component that processes untrusted input, particularly interpreters or runtimes, requires continuous and proactive security review, threat modeling, and extensive fuzzing from its inception.

About the Speaker(s)

Nan Wang (sakura) and Ziling Chen (R1nd0) are highly accomplished Security Researchers at Cyber Kunlun, specializing in browser security. Their expertise is widely recognized, as evidenced by their consistent ranking among the top three researchers in the Chrome Vulnerability Reward Program (VRP) from 2022 to 2024. The research presented on Dropbear alone, encompassing 23 distinct vulnerabilities, would secure them a ninth-place ranking on the Microsoft Security Response Center (MSRC) leaderboard. Both researchers are frequent presenters at prestigious security conferences, having shared their insights at events such as Black Hat USA, Black Hat Asia, and Zerocon. Their work consistently pushes the boundaries of browser exploitation and contributes significantly to the broader security community.