# Разбор презентации: Cross-Site Escape

## Материал
- **Название:** *Cross-Site Escape: Pwning macOS Safari Sandbox the Unusual Way*
- **Автор доклада:** Zhi Zhou (Zhou Zhi; в транскрипте также указан @CodeColorist).
- **Площадка и дата:** Black Hat Europe 2020; страница Speaker Deck датирована 6 декабря 2020 года и опубликована профилем `cc` (`chichou`).
- **Формат:** PDF, 2,130,845 байт.
- **Локальная копия:** [`safari_sandbox_escape.pdf`](safari_sandbox_escape.pdf)
- **Источник:** https://speakerdeck.com/chichou/cross-site-escape-pwning-macos-safari-sandbox-the-unusual-way
- **Прямая ссылка на PDF:** https://files.speakerdeck.com/presentations/8d3d8e156509429599234b772579d698/eu-20-Zhou-Cross-Site-Escape-Pwning-MacOS-Safari-Sandbox-The-Unusual-Way.pdf

## Цель и контекст
Доклад исследует, как перейти от исполнения JavaScript в Safari/WebContent к действиям в более привилегированных системных компонентах macOS, используя XSS-подобное внедрение в контекст другого процесса, IPC и забытые legacy WebView. Центральная мысль: цепочка может обходить границы процессов и песочницу без повторной эксплуатации WebKit для второго memory-corruption RCE; сами цепочки, однако, могли начинаться с уязвимости в renderer. Авторы подчёркивают, что memory-safety mitigations не устраняют ошибки доверия, IPC и логики между компонентами.

Материал охватывает несколько исторических примеров — от старых версий OS X/macOS до Catalina 10.15.2; это не описание актуального состояния исправленных систем.

## Основные техники и кейсы
1. **TOCTOU в проверке sandbox через CFPreferences (macOS ≤ 10.13 в описанном кейсе).** WebContent на раннем этапе инициализации обращался к CFPreferences до включения sandbox. По разбору докладчика, `cfprefsd` проверял состояние процесса один раз и кэшировал его; последующие запросы могли восприниматься как исходящие от несandboxed процесса. Это создавало возможность произвольного чтения/записи plist через соответствующий путь CFPreferences. Это логическая гонка/ошибка порядка и кэширования, а не классический memory corruption.
2. **Dashboard через XSS и IPC к Dock.** Получив доступ к записи plist, цепочка устанавливала виджет и меняла настройки Dashboard. Встроенный Dashboard WebView мог предоставлять мост `widget.system` при соответствующей настройке; доступный из WebContent MIG-интерфейс Dock и недокументированные API использовались, чтобы включить/активировать Dashboard. Так JavaScript попадал в контекст с возможностью запуска системных команд. Dashboard удалён начиная с macOS 10.15.
3. **HelpViewer и доверенная URL-схема.** Safari автоматически открывал некоторые схемы, включая `x-apple-helpbasic`, в подписанном Apple приложении HelpViewer без обычного подтверждения; для этой схемы доклад описывает проверку домена `.apple.com`. HelpViewer использовал legacy WebView без sandbox/JIT. Сценарий мог дать выход из renderer sandbox, а дальнейшее выполнение требовало отдельной DOM-уязвимости. Также исследовалась обработка `help:` через `NSURLProtocol` и чтение локальных файлов; показанные варианты доставки/монтирования имели ограничения, в частности на macOS 10.15 вариант через Finder требовал подтверждения. Докладчик отмечает, что этот кейс дал частичный результат/CVE-2020-9860, но не завершённую native-code цепочку.
4. **Dictionary / CVE-2020-9979 — подмена словарного ресурса.** Доступный из WebContent `mobileassetd` и частные API MobileAssets позволяли задать удалённый URL и заменить некоторые словарные assets; для типа DictionaryServices доклад указывает на whitelist без требуемого entitlement и отсутствие `com.apple.quarantine` у загруженного ресурса. WebKit IPC открывал окно Lookup/Dictionary без подтверждения. XSS/JavaScriptCore-эксплойт инициировал переход, вредоносный словарный контент выполнялся в legacy WebView Dictionary, а ссылка `file://` на приложение обрабатывалась делегатом через `NSWorkspace openURL`/LaunchServices. В описанной цепочке запущенный процесс не наследовал sandbox Dictionary.

## Схема цепочки Dictionary из доклада
1. Первичное выполнение в Safari/WebContent (XSS после renderer-эксплойта в полном сценарии).
2. Через доступный IPC и MobileAssets подготовить вредоносный словарный asset.
3. Создать выделение текста и вызвать WebKit lookup IPC; LookupViewService открывает Dictionary без подтверждения.
4. Dictionary загружает контролируемый контент в собственный legacy WebView.
5. Делегат Dictionary открывает ссылку на локальное приложение через системный механизм запуска — выполнение оказывается вне исходной песочницы.

## Выводы докладчика
- Системные поверхности атаки шире публичных API: важны XPC/MIG, WebKit IPC, URL-схемы, делегаты WebView, мосты JavaScript–Objective-C и обработчики ресурсов/навигации.
- Legacy-компоненты и привилегированные WebView могут снижать общий уровень защиты даже при изолированном современном renderer.
- Нужно проверять не только memory safety, но и доверие между компонентами, sandbox-политику, ранние обращения до sandbox lockdown, whitelist ресурсов/URL и поведение межпроцессных делегатов.
- Обход sandbox и native code execution — разные этапы цепочки: кейс HelpViewer, например, требовал дополнительной DOM-уязвимости для native execution.