By 
After years of development, Google deploys V8 sandbox, adding a necessary layer of memory security to Chrome
V8’s complex mix of interpreters and optimizing compilers represent a playing field for hackers. Memory safety in hand-written runtime code usually isn’t enough, as bugs often originate in machine code generated by the engine.
Over the past three years, 60% of Chrome exploits granting remote code execution (RCE) began as V8 vulnerabilities.
Why Existing Memory Mitigations Were Not Enough
Memory-safe languages like Rust offers robust protection within the interpreter code. However, this safety guarantee doesn’t automatically extend to the optimizing just-in-time (JIT) compilers (V8). Often, attackers target the machine code produced by the compiler, exploiting logic flaws.
Hardware-based features like memory tagging are not entirely fool-proof. Side-channels within JavaScript could potentially leak tag values, reducing their effectiveness. More info in the research paper – “Hardware-Based Always-On Heap Memory Safety“.
The V8 Sandbox: A New Defense
The core strategy is to isolate V8’s heap memory, preventing corruption from spreading. Similar concept of the user-kernel space separation is used in modern operating systems. Key to this is sandboxing pointers:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// Original Object (unsafe) class JSArrayBuffer: public JSObject { private: byte* buffer_; // Direct pointer to out-of-sandbox memory size_t size_; // Unbounded size }; // Sandbox-aware Object class JSArrayBuffer: public JSObject { private: sandbox_ptr_t buffer_; // 40-bit offset, limited to sandbox sandbox_size_t size_; // Size also sandbox-constrained }; |
Even if corrupted, sandboxed pointers can’t directly escape sandbox bounds.
The sandbox’s design solved more problems:
- Strict bounds checks, to prevent cases where a corrupted value might create an invalid array index. V8 developers have already patched a significant number of bugs due to this. For example, a recent one.
- Testing infrastructure. V8 exposes a ‘memory corruption API’ for testing.
In conclusion
The V8 Sandbox has already been enabled by default on 64-bit (specifically x64 and arm64) versions of Chrome on Android, ChromeOS, Linux, macOS, and Windows for roughly the last two years.
The announcement from V8 marks a major shift in JavaScript engine security (finally). As the sandbox matures, it’s likely to become a focus area for security researchers and vulnerability hunters.