Browser Sandbox.

A browser sandbox is the set of operating-system mechanisms a browser uses to constrain less-trusted child processes — renderers, GPU process, network service — to a minimal set of capabilities. Chromium relies on Windows job objects and integrity levels, macOS Seatbelt, and Linux seccomp-bpf plus user namespaces; Firefox uses comparable primitives. Even if attacker JavaScript triggers memory corruption inside the renderer, the sandbox blocks arbitrary file access, process creation, and syscalls without a second bug — a sandbox escape.

This two-bug requirement is visible at Pwn2Own. At the March 2024 event, Manfred Paul's winning Chrome entry used CVE-2024-2887, a type-confusion flaw in the V8 WebAssembly engine, to get read/write in the renderer — but that alone stayed trapped inside the process. The same contest surfaced CVE-2024-2886 (a use-after-free in WebCodecs) and CVE-2024-3159 (out-of-bounds read in V8). Chrome layers further defence with Site Isolation, which puts each site in its own renderer to blunt Spectre-style speculative-execution leaks, and the V8 heap sandbox ("Ubercage") that contains corruption even before the OS sandbox applies.

Defences that strengthen the model: keeping browsers auto-updated, enabling Site Isolation and enhanced sandbox flags, disabling unneeded plugins, and using per-site process limits so a single renderer compromise cannot span origins.

flowchart TD
  A[Malicious web page] --> B[Renderer process<br/>untrusted, low privilege]
  B --> C{Memory-corruption bug?<br/>e.g. CVE-2024-2887}
  C -->|No| D[Attack contained]
  C -->|Yes| E[Arbitrary R/W in renderer]
  E --> F{V8 heap sandbox<br/>+ OS sandbox}
  F -->|No escape bug| G[Still confined:<br/>no files, no syscalls]
  F -->|Sandbox-escape bug| H[Broker / kernel reached]
  H --> I[Full host code execution]