Are your Sites Truly Isolated? Automatically Detecting Logic Bugs in Site Isolation Implementations

Are your Sites Truly Isolated? Automatically Detecting Logic Bugs in Site Isolation Implementations

Speakers: Jan Drescher

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=_c7rnQveWxA

Overview

Site isolation is a critical browser security architecture that enforces separation between web applications by placing cross-site content into separate sandboxed renderer processes. This talk presents a novel IPC fuzzing approach to automatically detect site isolation bypass vulnerabilities -- logic bugs that allow a compromised renderer process to access cross-site data or execute scripts in another renderer. The researchers analyze all 39 known site isolation bypass CVEs in Chrome and Firefox, identify three attack classes (missing checks, circumventable checks, origin confusion), and build a fuzzer combining Web IDL-based grammar generation, IPC message mutation, and two new sanitizers: a process sanitizer detecting cross-site renderer reuse and a leak sanitizer detecting cross-site data leakage.

The system discovered 4 bugs in Chrome and Firefox, including one that received a CVE for URL spoofing via the history.replaceState API in Firefox, and achieves higher code coverage than the related FuzOrigin fuzzer.

Background

▶ Watch: What is site isolation and how renderer processes communicate (0:00)

Modern browsers implement site isolation by placing content from different sites (defined as scheme + eTLD+1, e.g., HTTPS + example.com) into separate sandboxed renderer processes. These renderer processes communicate with the privileged browser process via Inter-Process Communication (IPC). The browser process also manages connections to GPU, network, and storage service processes, creating a complex web of IPC channels.

A site isolation bypass occurs when an attacker who has compromised one renderer process gains access to data or can execute scripts in another renderer process. The compromised renderer has complete control of its code and can send arbitrary IPC messages to the browser process. If the browser process fails to properly validate these messages against the renderer's authorized site, cross-site data access becomes possible.

The researchers evaluated all 39 known site isolation bypass vulnerabilities in Chrome and Firefox, categorizing them into three classes:

1. Missing security checks: The browser process simply doesn't validate, or checks are only implemented in the renderer (where they can be circumvented)
2. Circumventable checks: Security checks that can be bypassed, for example during renderer shutdown when managing objects are deleted and object-dependent checks are skipped
3. Origin confusion: During complex cross-site navigation sequences, the browser process mixes up site labels for processes, corrupting its authorization information

Critically, all these bugs are semantic/logic bugs that are invisible to memory safety tools like AddressSanitizer, requiring a different detection approach.

Key Findings

▶ Watch: 2018 Chrome blob registry bypass: 27 bytes content in 2KB file (4:00)

• 4 bugs discovered in Chrome and Firefox, including a CVE for URL spoofing via history.replaceState in Firefox allowing cross-site content loading in an attacker-controlled renderer
• All 39 known site isolation bypasses are semantic bugs, not memory safety issues -- AddressSanitizer cannot detect them
• Three distinct attack classes identified: missing checks, circumventable checks, and origin confusion
• Higher coverage than FuzOrigin: The fuzzer achieves more code coverage than the related FuzOrigin fuzzer for universal cross-site scripting bugs
• 99% of the blob object in the 2018 Chrome exploit was validation material, with only 27 bytes of actual authorization content -- illustrating the attack surface complexity of IPC validation
• Reproducible crashes through synchronized JavaScript generation and IPC mutation

Technical Deep Dive

▶ Watch: Process sanitizer and leak sanitizer for runtime detection (8:00)

The fuzzer operates at two layers simultaneously: JavaScript API interaction and IPC message mutation.

Web IDL Grammar-Based Generation: To cover all APIs and IPC interactions that could trigger site isolation bugs, the fuzzer generates JavaScript using a grammar derived from Web IDL (Web Interface Definition Language) interface specifications. This ensures comprehensive API coverage. The grammar favors the Navigation API to trigger the complex cross-site navigation sequences that cause origin confusion.

IPC Message Mutation: A compromised renderer's power lies in sending arbitrary IPC messages. The fuzzer patches the browser's IPC interface generation code (Mojo definition files for Chrome) to insert hooks into all send methods, enabling manipulation of message parameters before they are serialized. This approach requires minimal browser source code changes, making it maintainable across browser versions.

Process Sanitizer: Detects cross-site renderer process reuse. A JavaScript API tags each document's origin/site to its renderer process on first invocation. On subsequent invocations, the tag is compared -- if cross-site content appears in a tagged process, the sanitizer reports a violation. The limitation: this tag lives in the renderer, so it wouldn't survive a real renderer compromise. It works for fuzzing because the fuzzer controls both processes.

Leak Sanitizer: Detects cross-site data leakage by injecting a known secret string into the victim renderer's JavaScript APIs. All incoming IPC messages to the attacker renderer are searched for the secret string. If found, cross-site data has leaked.

Synchronized Fuzzing: The JavaScript generation and IPC mutation operate at different layers but need coordination. A JavaScript API allows the fuzzer to enqueue IPC mutations that execute on the next matching outgoing message, enabling reproducible exploits. For example, the blob registry exploit can be written as: create blob, enqueue URL host replacement mutation, call createObjectURL, navigate to the mutated URL.

Demo / Proof of Concept

▶ Watch: IPC hook injection via Mojo definition file patching (10:00)

The most significant finding is the Firefox history.replaceState URL spoofing vulnerability (assigned a CVE). This bug allowed spoofing the URL in IPC messages created by the history.replaceState API, enabling loading of cross-site content in an attacker-controlled renderer process.

The evaluation includes coverage comparison against FuzOrigin, showing the fuzzer achieves higher browser process coverage (the critical code for site isolation enforcement). The fuzzer was also validated against known vulnerabilities in old browser versions.

The Q&A revealed current limitations: overall browser code coverage is 2-6% (typical for browser fuzzing given the enormous codebase), and throughput is limited because the renderer process is killed whenever the browser process detects spoofing attempts, requiring snapshot-based optimization for future improvement.

Defensive Implications

▶ Watch: Q&A: coverage limitations and future directions for browser fuzzing (14:00)

• Systematic IPC validation auditing: The fuzzer provides a systematic approach to testing whether the browser process correctly validates all IPC messages from renderer processes, complementing manual code review
• Navigation complexity as attack surface: Complex cross-site navigation sequences are a primary source of origin confusion bugs, suggesting that simplifying navigation state management could reduce the attack surface
• Semantic bug detection gap: The finding that all site isolation bypasses are semantic bugs highlights the limitations of memory safety tools (AddressSanitizer, etc.) and the need for logic-level sanitizers in browser security testing
• Browser process as security boundary: The browser process is the critical trust boundary -- all security checks must be implemented there, not in renderer processes that may be compromised

Key Takeaways

• Site isolation bypass vulnerabilities are logic/semantic bugs invisible to memory safety tools like AddressSanitizer
• Three attack classes: missing security checks, circumventable checks, and origin confusion during complex cross-site navigation
• A novel IPC fuzzer combining Web IDL grammar generation with IPC message mutation discovers 4 bugs including a Firefox CVE
• The process sanitizer and leak sanitizer provide runtime detection of cross-site renderer reuse and data leakage respectively
• Patching IPC interface generation code (Mojo files) enables comprehensive hook coverage with minimal browser source changes
• The fuzzer achieves higher coverage than FuzOrigin but overall browser coverage remains low (2-6%) due to codebase size

About the Speaker(s)

Jan Drescher presented this research with clear command of both the browser security architecture and the fuzzing methodology. The Q&A engaged researchers from the University of Leuven/Google, demonstrating the work's relevance to browser security teams. The technical depth of the IPC hooking approach and the synchronized fuzzing mechanism shows significant engineering effort beyond typical academic fuzzing papers.