Pierluigi Paganini
April 09, 2024
Google has announced support for what’s called a V8 Sandbox in the Chrome web browser. The company included the V8 Sandbox in Chrome’s Vulnerability Reward Program (VRP). Chrome 123 is a sort of “beta” release for the sandbox designed to mitigate memory corruption issues in the Javascript engine.
The V8 Sandbox is designed to prevent memory corruption issues that would impact other areas of memory in the process.
Almost every Chrome exploits observed in the wild between 2021 and 2023 triggered a memory corruption issue in a Chrome renderer process that was exploited for remote code execution (RCE). The majority of these issues (60%) impacted the V8 Javascript engine.
“V8 vulnerabilities are rarely “classic” memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8.” reads the announcement. “In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.”
The researchers highlighted that a common thread among nearly all V8 vulnerabilities is that the eventual memory corruption occurs within the V8 heap. This is primarily because the compiler and runtime predominantly deal with V8 HeapObject instances.
To mitigate such vulnerabilities the researchers devised a technique to isolate V8’s (heap) memory to prevent memory corruption from spreading to other parts of the process’ memory.
“The sandbox limits the impact of typical V8 vulnerabilities by restricting the code executed by V8 to a subset of the process’ virtual address space (“the sandbox”), thereby isolating it from the rest of the process. This works purely in software (with options for hardware support, see the respective design document linked below) by effectively converting raw pointers either into offsets from the base of the sandbox or into indices into out-of-sandbox pointer tables. In principle, these mechanisms are very similar to the userland/kernel separation used by modern operating systems (e.g. the unix file descriptor table).” states Google. “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. 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.”
Software-based sandbox replaces data types that can access out-of-sandbox memory with “sandbox-compatible” alternatives.
In the software-based sandbox, only the V8 heap is enclosed within the sandbox. As a result, the overall structure is similar to the sandboxing model employed by WebAssembly.
The researchers state that the majority of the overhead generated by the sandbox primarily arises from the pointer table indirection for external objects. A minor overhead is related to the use of offsets instead of raw pointers, primarily involving a shift+add operation, anyway this is quite inexpensive. The sandbox’s overhead is approximately 1% or less on standard workloads, as determined by measurements using the Speedometer and JetStream benchmark suites. Consequently, the V8 Sandbox can be activated by default on compatible platforms.
“The V8 Sandbox must be enabled/disabled at build time using the v8_enable_sandbox build flag. It is (for technical reasons) not possible to enable/disable the sandbox at runtime. The V8 Sandbox requires a 64-bit system as it needs to reserve a large amount of virtual address space, currently one terabyte.” concludes the announcement.
“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.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, V8 Sandbox)
