Google Chrome Adds V8 Sandbox - A New Defense Against Browser Attacks
9.4.24  Safety  The Hacker News

Google has announced support for what's called a V8 Sandbox in the Chrome web browser in an effort to address memory corruption issues.

The sandbox, according to V8 security technical lead Samuel Groß, aims to prevent "memory corruption in V8 from spreading within the host process."

The search behemoth has described V8 Sandbox as a lightweight, in-process sandbox for the JavaScript and WebAssembly engine that's designed to mitigate common V8 vulnerabilities.

The idea is to limit the impact of V8 vulnerabilities by restricting the code executed by V8 to a subset of the process' virtual address space ("the sandbox") and isolating it from the rest of the process.

Shortcomings affecting V8 have accounted for a significant chunk of the zero-day vulnerabilities that Google has addressed between 2021 and 2023, with as many as 16 security flaws discovered over the time period.

"The sandbox assumes that an attacker can arbitrarily and concurrently modify any memory inside the sandbox address space as this primitive can be constructed from typical V8 vulnerabilities," the Chromium team said.

"Further, it is assumed that an attacker will be able to read memory outside of the sandbox, for example, through hardware side channels. The sandbox then aims to protect the rest of the process from such an attacker. As such, any corruption of memory outside of the sandbox address space is considered a sandbox violation."

Groß emphasized the challenges with tackling V8 vulnerabilities by switching to a memory-safe language like Rust or hardware memory safety approaches, such as memory tagging, given the "subtle logic issues" that can be exploited to corrupt memory, unlike classic memory safety bugs like use-after-frees, out-of-bounds accesses, and others.

"Nearly all vulnerabilities found and exploited in V8 today have one thing in common: the eventual memory corruption necessarily happens inside the V8 heap because the compiler and runtime (almost) exclusively operate on V8 HeapObject instances," Groß said.

Given that these issues cannot be protected by the same techniques used for typical memory-corruption vulnerabilities, the V8 Sandbox is designed to isolate V8's heap memory such that should any memory corruption occur, it cannot escape the security confines to other parts of the process' memory.

This is accomplished by replacing all data types that can access out-of-sandbox memory with "sandbox-compatible" alternatives, thereby effectively preventing an attacker from accessing other memory. The sandbox can be enabled by setting "v8_enable_sandbox" to true in the gn args.

Benchmark results from Speedometer and JetStream show that the security feature adds an overhead of about 1% on typical workloads, allowing it to be enabled by default starting with Chrome version 123, spanning Android, ChromeOS, Linux, macOS, and Windows.

"The V8 Sandbox requires a 64-bit system as it needs to reserve a large amount of virtual address space, currently one terabyte," Groß said.

"The sandbox is motivated by the fact that current memory safety technologies are largely inapplicable to optimizing JavaScript engines. While these technologies fail to prevent memory corruption in V8 itself, they can in fact protect the V8 Sandbox attack surface. The sandbox is therefore a necessary step towards memory safety."

The development comes as Google highlighted the role by Kernel Address Sanitizer (KASan) in detecting memory bugs in native code and help harden Android firmware security, adding it used the compiler-based tool for discovering more than 40 bugs.

"Using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices," Eugene Rodionov and Ivan Lozano from the Android team said.