To address memory corruption issues, Google has announced support for the so-called V8 Sandbox in the Chrome web browser.

Samuel Groß, the technical lead for V8 security, states that the sandbox is intended to stop “memory corruption in V8 from spreading within the host process.”

According to the search giant, V8 Sandbox is a lightweight, in-process sandbox for the JavaScript and WebAssembly engine intended to minimize common V8 vulnerabilities.

The Role of a Cybersecurity Specialist

By limiting the code executed by V8 to a portion of the process’ virtual address space (referred to as “the sandbox”) and isolating it from the remainder of the process, the impact of V8 vulnerabilities is intended to be mitigated.

Up to 16 security issues were found over that time, and V8 shortcomings accounted for a sizable portion of the zero-day vulnerabilities that Google fixed between 2021 and 2023.

“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,” according to the Chromium team.

It is also anticipated that an attacker will be able to access memory using hardware-side channels, for example, and read data outside of the sandbox. The goal of the sandbox is to keep the attacker away from the remainder of the process. Therefore, a sandbox violation is defined as any memory corruption that occurs outside of the sandbox address area.

Unlike classic memory safety bugs like use-after-frees, out-of-bounds accesses, and others, Groß highlighted the difficulties in addressing V8 vulnerabilities by moving to a memory-safe language like Rust or hardware memory safety approaches, like memory tagging, given the “subtle logic issues” that can be exploited to corrupt memory.

“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ß stated.

The V8 Sandbox is designed to isolate V8’s heap memory so that, should memory corruption occur, it cannot escape the security bounds to other areas of the process memory. These issues cannot be addressed using the same mechanisms used for ordinary memory corruption vulnerabilities.

By substituting “sandbox-compatible” data types for all data types that can access memory outside of the sandbox, this effectively stops an attacker from accessing other memory. Setting “v8_enable_sandbox” to true in the gn args will activate the sandbox.

Speedometer and JetStream benchmark findings indicate that the security feature adds approximately 1% overhead on typical workloads, which enables Chrome version 123 to be enabled by default across 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ß stated.

The sandbox was created because JavaScript engine optimization is not a good fit for the majority of memory safety methods available today. These technologies can shield the V8 Sandbox attack surface, but they are unable to stop memory corruption in V8 itself. Thus, a crucial first step toward memory safety is the sandbox.”

This development coincides with Google highlighting the function of Kernel Address Sanitizer (KASan) in hardening Android firmware security by identifying memory issues in native code. Google added that over 40 bugs were found using the compiler-based tool.

Eugene Rodionov and Ivan Lozano of the Android team stated that “using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices.”

SOURCE