Простые тестовые примеры полезны, чтобы убедиться, что система ведёт себя ожидаемым образом. Иногда необъяснимое расхождение открывает неожиданно обширную область исследований. Это история одного такого расхождения и скрывавшейся за ним кроличьей норы безопасности.

Всё казалось таким ясным...

Окна на одном рабочем столе обычно могут взаимодействовать: перемещать друг друга, изменять размеры, закрывать или отправлять ввод. Это становится опасным, когда один процесс работает с повышенными привилегиями. Изоляция привилегий пользовательского интерфейса (UIPI) не позволяет окнам с более низким уровнем целостности отправлять опасные команды окнам с более высоким.

win32k!NtUserPostMessage проверяет, разрешил ли получатель сообщение явно или входит ли оно в небольшой безопасный белый список:

Я написал тест, который отправлял все возможные сообщения из непривилегированного процесса привилегированным окнам. Результат должен был совпасть с белым списком. Но не совпал.

Сообщения из диапазона 0xCNNN принимали многие приложения, включая Блокнот. Windows резервирует следующие диапазоны:

Эти диапазоны описаны в документации по WM_USER и WM_APP.

Что, строковые сообщения?

RegisterWindowMessage() позволяет независимым приложениям согласовать номер на основе общей строки, вероятно, через таблицы атомов Windows.

Моя первая теория заключалась в том, что регистрация неявно вызывает ChangeWindowMessageFilterEx(). Тестирование её опровергло. Фильтры явно изменяло что-то другое.

Поиск виновника

Я поставил точку останова на USER32!RegisterWindowMessageW и продолжал выполнение, пока функция не вернула один из подозрительных номеров:

Пока ядро создаёт окно, оно вызывает callback, загружающий MSCTF. Эта библиотека регистрирует сообщения и изменяет их фильтры.

Открываются скрытые глубины...

CTF относится к Text Services Framework Windows, который управляет раскладками клавиатуры, методами ввода, распознаванием рукописного текста и обработкой текста. В примечаниях Microsoft по безопасности говорилось, что TSF был усилен для ограничения враждебного доступа к стеку, куче и защищённой памяти. Эта формулировка не внушала доверия к прежней архитектуре, поэтому я потратил несколько недель на её обратную разработку.

Так как же всё это работает?

ctfmon.exe уведомляет приложения об изменениях раскладки клавиатуры и методов ввода. Ядро принудительно подключает приложения при создании ими окон.

Редактор метода ввода, например Microsoft Pinyin, должен наблюдать за вводом с клавиатуры и заменять текст в другом процессе. Такой внепроцессный компонент называется обработчиком текстового ввода (Text Input Processor, TIP).

Разбираемся с протоколом CTF

Каждый рабочий стол и сеанс получает службу-монитор с ALPC-портом, имя которого выглядит так:

USER32!CtfHookProcWorker загружает клиент, который подключается и сообщает HWND, идентификатор потока и идентификатор процесса:

Сервер ожидает непрерывно. Клиенты опрашивают его только после получения зарегистрированного оконного сообщения, что объясняет вызовы RegisterWindowMessage().

Клиенты отправляют команды монитору или просят его переслать команды другому потоку:

Десятки команд передают данные или создают экземпляры COM-объектов. Сложный формат маршалинга добавляет типизированные параметры:

Сигнатура прокси сообщает монитору, какой созданный COM-объект и какой его метод должны получить маршалированные данные.

CTF стар. Самая ранняя найденная версия MSCTF поставлялась с Office XP в 2001 году и поддерживала Windows 98. В Windows XP он вошёл в состав ОС. Vista перенесла протокол с LPC на ALPC, но его архитектура почти не изменилась.

Есть ли здесь поверхность атаки?

Содержательного контроля доступа не было. Любое приложение или пользователь, включая процесс в песочнице, могли подключиться к любому сеансу CTF. Клиенты без аутентификации сообщали идентификатор потока, идентификатор процесса и HWND и могли лгать. Атакующий также мог выдать себя за службу CTF и заставить привилегированные приложения подключиться к нему.

Даже штатные возможности, по-видимому, позволяли пересекать границы песочниц и привилегий. Для их исследования я создал интерактивный клиент ctftool с поддержкой сценариев, переменных, арифметики и управления потоком выполнения.

Исследование CTF с помощью ctftool

Инструмент подключается к сеансу и перечисляет клиентов:

Он может дождаться Блокнота, запросить создание COM-объекта и вызвать методы через возвращённую заглушку.

Например, можно создать экземпляр ITfInputProcessorProfileMgr, подготовить GUID и выходной буфер, а затем вызвать GetActiveProfile:

Удалённый процесс заполняет предоставленный буфер своим активным профилем ввода.

Поиск ошибок

Устаревший недокументированный протокол содержал множество ошибок повреждения памяти. COM-объекты доверяли маршалированным указателям, а проверки границ и целочисленного переполнения были минимальными. Ограничения вроде владения окном переднего плана были бесполезны, поскольку клиенты могли лгать о своих идентификаторах потоков.

Команда вызова COM-заглушки принимала непроверенный индекс таблицы методов:

CTF перехватывает исключения, поэтому целевой процесс не завершается. Атакующий получает неограниченное число попыток.

Control Flow Guard ограничивает косвенные цели, но оставляет огромное количество допустимых адресов перехода. Примитив разыменовывает произвольный указатель на функцию, передавая this и частично контролируемый указатель на сообщение в качестве аргументов. Я вызвал все возможные индексы и записал возникающие исключения.

Индекс 496 приводил к MSCTF!CTipProxy::Reconvert, которая перемещала несколько регистров вблизи контролируемых данных и выполняла переход по контролируемому указателю. Такое состояние было гораздо полезнее для эксплуатации.

Примечание об ASLR

Windows рандомизирует системные DLL при каждой загрузке, а не для каждого процесса, поэтому адреса кода можно узнать из непривилегированного процесса и повторно использовать в привилегированной цели. Стеки по-прежнему рандомизируются отдельно для каждого процесса, и, если нужны данные стека, потребуется утечка.

Просмотр доступных гаджетов

Благоприятное состояние вызова, допустимого CFG, позволяло с помощью поддельных объектов выстраивать цепочки гаджетов, задавать регистры и в итоге возвращаться в LoadLibrary(). Это позволяло скомпрометировать произвольных клиентов CTF, включая Блокнот.

Переходим к последствиям

На каждом рабочем столе есть сервер CTF, в том числе в сеансах служб и на защищённом рабочем столе Winlogon. ctftool может захватить блокировку, подключиться к другому сеансу или рабочему столу и взаимодействовать с привилегированными клиентами:

Таким образом, непривилегированный процесс может атаковать клиентов SYSTEM и добиться выполнения кода от имени SYSTEM.

CTF также позволяет манипулировать текстом без непосредственного выполнения кода. Вредоносный TIP может запрашивать сеансы редактирования, просматривать и заменять диапазоны текста и вмешиваться в работу приложений, доверяющих содержимому своего интерфейса.

Сам диалог подтверждения UAC является клиентом CTF, работающим от имени SYSTEM. Защищённый рабочий стол не помогает, поскольку в CTF отсутствовал соответствующий контроль доступа.

Заключение

CTF представлял собой огромную, практически недокументированную поверхность атаки, автоматически загружавшуюся почти в каждый процесс с графическим интерфейсом. Его модель доверия позволяла неаутентифицированным клиентам заявлять произвольные идентификаторы, обращаться к другим клиентам, маршалировать сложные данные и вызывать методы COM. Ошибки на этой поверхности пересекали границы уровней целостности, песочниц, сеансов и защищённого рабочего стола.

Исследование началось с нескольких неожиданных номеров оконных сообщений. Проверка предположения, отказ игнорировать расхождение и затрата большего времени, чем казалось разумным, раскрыли протокол, почти два десятилетия существовавший незаметно.

Проект ctftool и подробные заметки об эксплуатации были опубликованы, чтобы архитектуру и её риски можно было изучить и устранить. Общий вывод прост: повсеместная, автоматическая и невидимая инфраструктура совместимости заслуживает такого же внимания, как и новые границы безопасности.

В начале этого года группа анализа угроз Google (TAG) обнаружила небольшую группу взломанных сайтов, использовавшихся для неизбирательных атак типа watering hole на посетителей с iPhone. Сервер эксплойтов не выбирал конкретные цели: для запуска атаки было достаточно зайти на один из сайтов. В случае успешной эксплуатации сервер устанавливал имплант для слежения. По нашим оценкам, каждую неделю эти сайты посещали тысячи людей.

TAG собрала пять полных и различных цепочек эксплойтов iPhone, охватывающих почти все выпуски от iOS 10 до последней версии iOS 12. Свидетельства указывали на группу, которая как минимум два года целенаправленно пыталась взламывать iPhone участников определённых сообществ.

В этой серии исследуются вероятные первопричины и то, что они говорят о жизненном цикле разработки программ Apple. Выявленные закономерности не новы, но их часто упускают из виду: код, который, по-видимому, никогда не работал; код, скорее всего не проходивший содержательной проверки качества; и функции, выпущенные практически без признаков тестирования или рецензирования.

В пяти цепочках TAG и Project Zero выявили четырнадцать уязвимостей:

• Семь уязвимостей в браузере iPhone.

• Пять уязвимостей ядра.

• Два различных способа выхода из песочницы.

Первоначальный анализ показал, что на момент обнаружения как минимум одна цепочка повышения привилегий всё ещё не была исправлена: CVE-2019-7287 и CVE-2019-7286. Project Zero сообщила о них Apple 1 февраля 2019 года, установив семидневный срок. 7 февраля Apple вне очереди выпустила iOS 12.1.4 и в тот же день публично сообщила об исправлениях.

После нескольких месяцев исследования почти каждого байта каждой цепочки мы можем подробно описать реальную кампанию массовой эксплуатации iPhone. Связанные исследования включают:

• Цепочка эксплуатации iOS № 1

• Цепочка эксплуатации iOS № 2

• Цепочка эксплуатации iOS № 3

• Цепочка эксплуатации iOS № 4

• Цепочка эксплуатации iOS № 5

• Анализ эксплойтов JavaScriptCore

• Разбор импланта для слежения

Разбор импланта включает демонстрацию на наших собственных устройствах с восстановленным методом обратной разработки сервером управления. Она показывает, как имплант в реальном времени похищает личные данные, включая сообщения iMessage, фотографии и координаты GPS. Самуэль Гросс анализирует браузерные эксплойты, обеспечившие первоначальные точки входа.

Важно помнить, что обнаружение означает неудачу злоумышленника. Если одна кампания стала видна, почти наверняка существуют и другие, оставшиеся незамеченными.

Пользователи принимают решения о риске, опираясь на публичную репутацию безопасности устройства. Защитные меры не способны полностью устранить риск атаки на выбранного пользователя. При этом «целью» человек может стать только потому, что родился в определённом регионе или принадлежит к некоторой этнической группе. Мобильные устройства неотделимы от современной жизни, но взломанное устройство может отправлять сведения о действиях человека в базу данных и сохранять их для будущего использования.

Общественной дискуссии пора выйти за рамки образа «диссидента за миллион долларов» и обратиться к предельной стоимости слежения за следующим потенциальным диссидентом. Стоит ли одна цепочка один, два или двадцать миллионов долларов, менее важно, чем приобретаемая с её помощью возможность выбирать цели и в реальном времени следить за частной жизнью целых групп населения.

В основном имплант похищал файлы и передавал текущее местоположение. Каждые шестьдесят секунд он связывался с сервером управления. Чтобы безопасно продемонстрировать его возможности, Project Zero запустила имплант на iPhone 8 с iOS 12, подключив его к специально созданному серверу C2, протокол которого был восстановлен методами обратной разработки. Все приведённые ниже снимки экрана сделаны на этом тестовом устройстве.

Сообщения со сквозным шифрованием в состоянии покоя

Сквозное шифрование защищает сообщения при передаче и от поставщика сервиса, однако приложения хранят читаемые копии на конечном устройстве. Доступ с правами root за пределами песочницы позволяет импланту копировать эти базы данных.

WhatsApp

В приложении и похищенной базе данных один и тот же разговор отображается в виде открытого текста.

Telegram

Локальная база данных Telegram после компрометации конечного устройства аналогичным образом раскрывает отправленные и полученные сообщения.

iMessage

Несмотря на шифрование при передаче по сети, история iMessage доступна в базе данных сообщений устройства.

Hangouts

Простые SQL-запросы к переданной базе данных Google Hangouts раскрывают текст сообщений и URL общих изображений.

Gmail

Имплант может передавать закрытые файлы приложения, содержащие почтовые данные в виде открытого текста.

Другие персональные данные

Имплант собирает адресную книгу:

Он может перечислять и передавать фотографии:

Он также записывает текущее GPS-положение устройства:

Контекст выполнения

Имплант встроен в каждый Mach-O-файл повышения привилегий в секцию __DATA,__file. Поддельный порт задачи ядра, использованный при эксплуатации, уничтожается до запуска импланта. Сам имплант целиком состоит из кода пользовательского пространства, но работает без песочницы с правами root и выбранными атакующим разрешениями.

Этим разрешениям доверяют, поскольку эксплойт добавил хеш каталога кода импланта в динамический кеш доверия ядра. Исследование с помощью jtool показывает широкие права доступа к закрытым данным и сервисам устройства.

Обратная разработка

Бинарный файл представляет собой неоптимизированный Objective-C-код. В основном он состоит из двух классов, Service и Util, а также вспомогательных процедур. При запуске создаётся объект Service, вызывается его метод start, после чего начинается текущий цикл выполнения.

Инвентаризация устройства

При первоначальном сборе создаётся словарь с идентификаторами и сведениями о системе, включая имя и модель устройства, версию ОС, номер телефона при его наличии, серийный номер и аппаратные идентификаторы, локаль, часовой пояс и сетевые данные.

Имплант генерирует UUID и сериализует словарь в XML-список свойств по пути следующего вида:

Затем универсальной процедуре передачи возвращается отображение наподобие @{"device.plist": path}. Этот шаблон — преобразование собранных данных во временные файлы и передача словарей с именами файлов и путями функции postFiles — используется во всём импланте.

Цикл команд

Сразу после эксплуатации имплант выполняет около десятка массовых передач. Затем он устанавливает NSTimer, который каждые шестьдесят секунд вызывает timer_handle.

При каждом опросе серверу отправляются идентификационные данные устройства, после чего разбираются возвращённые команды. Поддерживаются следующие операции:

• Передача сведений об устройстве и сети.

• Передача контактов, журнала вызовов, баз данных SMS/iMessage, заметок и голосовых записей.

• Перечисление установленных сторонних приложений.

• Передача выбранных каталогов контейнеров приложений.

• Передача фотографий и других медиафайлов.

• Чтение записей связки ключей и материалов аутентификации.

• Запуск или остановка отслеживания местоположения и передача GPS-координат.

• Выполнение дополнительных выбранных сервером операций сбора.

После передачи временные архивы и списки свойств удаляются. Сетевые запросы содержат достаточно идентификаторов, чтобы сервер мог связать каждый опрос и набор файлов с конкретной жертвой.

Содержимое приложений

В каталогах контейнеров сторонних приложений хранится основная часть их данных. Имплант содержит жёстко заданный список идентификаторов пакетов ценных приложений, контейнеры которых автоматически передаются при наличии на устройстве. Сервер C2 также может запросить полный список установленных приложений и выбрать дополнительные контейнеры.

Среди целей находятся популярные приложения для общения и электронной почты, в том числе WhatsApp, Telegram, Gmail, Hangouts и другие. Именно так имплант получает читаемые локальные копии разговоров со сквозным шифрованием.

Токены аутентификации

Данные связки ключей и контейнеров могут сохранить ценность даже после утраты непосредственного доступа к устройству. В ходе демонстрации похищенный токен OAuth Gmail был повторно использован за пределами телефона:

С помощью токена была аутентифицирована новая сессия Gmail:

Это важное различие. Сам бинарный файл не обладает устойчивостью, но учётные данные, похищенные во время одного успешного посещения, могут сохранить доступ к облачным учётным записям после перезагрузки телефона.

Последствия

Имплант может передать операторам почти всю доступную на устройстве персональную информацию в незашифрованном виде. В неё входят личные сообщения, почта, контакты, фотографии, история местоположений, базы данных приложений и токены аутентификации.

Имплант не обеспечивает устойчивость после загрузки. Перезагрузка останавливает его, и устройство должно снова посетить скомпрометированный сайт и подвергнуться эксплуатации. Тем не менее похищенные из связки ключей токены могут позволить операторам сохранять постоянный доступ к сервисам и учётным записям, не сохраняя контроль над телефоном.

Пять цепочек для ядра различаются, но все приводят к одному результату: слежке. Компрометация конечного устройства сводит на нет практическую конфиденциальность зашифрованных приложений, поскольку открытый текст должен существовать там, где пользователь его читает и пишет.

Техники в этой цепочке указывают, что её разрабатывали одновременно с iOS 10, а не адаптировали значительно позже. Это подтверждает вывод о том, что операторы не менее двух лет сохраняли возможность атаковать полностью обновлённые iPhone.

Первая уязвимость ядра

Точкой входа в ядро служит переполнение кучи в AGXAllocationList2::initWithSharedResourceList, части драйвера встроенного GPU com.apple.AGX. Она напрямую доступна из песочницы WebContent, поэтому отдельный выход из песочницы этой цепочке не нужен.

Общий входной буфер начинается с заголовка размером 0x18 байта. Последнее двойное слово в нём задаёт число следующих поддескрипторов размером 0x40 байта. Каждый поддескриптор заканчивается 16-разрядным числом подэлементов и содержит два параллельных массива: идентификаторы ресурсов в виде двойных слов и 16-разрядные флаги.

Драйвер доверяет значению n_entries из общей памяти и выделяет место в предположении, что на один дескриптор приходится не более шести подресурсов:

Атакующий управляет размером выделения и счётчиком каждого дескриптора. Дескрипторы с семью ресурсами вместо шести записывают один указатель за пределами ожидаемой области. Выбирая число дескрипторов с семью элементами, эксплойт записывает контролируемое количество указателей IOAccelResource2 * за пределы буфера IOMalloc.

Начало

Сначала эксплойт перечисляет потоки задачи WebContent с помощью task_threads() и завершает все, кроме текущего. Это уменьшает шум планировщика во время подготовки кучи.

Символы разрешаются через системный загрузчик. Хотя эксплойт использует IOSurface, он не скомпонован с этим фреймворком: вместо этого он вызывает dlopen() для IOSurface.dylib и разрешает IOSurfaceCreate и IOSurfaceGetID с помощью dlsym().

Определение системы

Эксплойт читает hw.machine через sysctl и получает модель вроде iPhone6,1. Функция CFCopySystemVersionDictionary() предоставляет ProductBuildVersion. Вместе эти значения однозначно определяют образ ядра, например iPhone6,1(14A403) для iOS 10.0.1 на iPhone 5S.

Архивированный NSDictionary в сегменте __DATA эксплойта сопоставляет поддерживаемые строки модели и сборки со смещениями и несдвинутыми указателями, которые используются позднее. Это веское свидетельство того, что цепочку поддерживали для конкретных сочетаний устройств и версий ОС.

Эксплуатация

IOSurface предоставляет удобный интерфейс к куче ядра. Привязанные к IOSurface свойства сериализуются в пользовательском пространстве, десериализуются в ядре в подклассы OSObject, а позднее копируются обратно. Хотя операции со свойствами дороги, они позволяют создавать в памяти ядра контролируемые OSData, словари, массивы, числа и строки.

Что такое IOKit?

IOKit — это C++-фреймворк Apple для драйверов устройств. Драйвер, доступный пользовательскому пространству, обычно содержит:

• Объект IOService, представляющий оборудование или логическую службу.

• Один или несколько объектов IOUserClient, представляющих отдельные подключения из пользовательского пространства.

Пользовательское пространство вызывает нумерованные внешние методы через право Mach на отправку, именующее IOUserClient. Методы принимают скалярные и структурные входные данные переменного размера и возвращают скалярные либо структурные выходные данные.

Подготовка триггера

Эксплойт находит службу AGX и открывает нужные пользовательские клиенты через IOServiceOpen. Профиль iOS com.apple.WebKit.WebContent.sb явно разрешает доступ к этой службе GPU, поэтому ошибка достижима из песочницы отрисовщика Safari.

Внешний метод 6, create_shmem, создаёт две общие области. Эксплойт заполняет одну заголовком списка выделений и поддескрипторами, а другую — вспомогательными данными ресурсов. Поскольку ядро многократно читает общую память, а не создаёт сначала неизменяемую копию, в критический момент значения остаются под контролем атакующего.

Подготовка кучи

Непосредственно перед запуском переполнения эксплойт создаёт около ста потоков. Поначалу это выглядело либо как попытка выиграть гонку, либо как техника подготовки кучи. Число потоков берётся из словаря смещений для конкретной сборки, что указывает на зависящую от устройства подготовку.

Каждый поток блокируется в recvmsg_x() на паре сокетов. Ядро выделяет массив объектов recv_msg_elem и выделения uio, описывающие буферы пользовательского пространства. Так в тех же размерных классах kalloc, на которые направлено переполнение AGX, создаётся воспроизводимый шаблон.

Подготовка кучи с recvmsg_x

На устройствах со страницами 4 КиБ семь потоков создают семь массивов recv_msg_elem, после чего одно специально подготовленное Mach-сообщение выделяет объект kalloc целевого размера, названный резервирующим выделением kalloc. Шаблон повторяется, чтобы хотя бы одно независимо освобождаемое резервирующее выделение с высокой вероятностью оказалось непосредственно перед массивом recv_msg_elem.

Эксплойт освобождает выбранные резервирующие выделения и создаёт пустоты:

Затем он запускает переполнение AGX из замещающего выделения, занявшего одну из пустот. Переполнение изменяет первый указатель uio * в соседнем массиве recv_msg_elem:

Вторая техника подготовки кучи: внестрочная память Mach

Резервирующие выделения размером 4 КиБ создаются специально подготовленными Mach-сообщениями с внестрочной памятью. Такие сообщения дают контролируемое выделение, время жизни которого можно независимо завершить, уничтожив сообщение или право на получение.

На устройствах с 16-КиБ страницами пятнадцать потоков recvmsg_x и следующее за ними резервирующее выделение создают шестнадцать объектов целевого размера, заполняя один блок аллокатора. Точные числа зависят от сборки и размера страницы, но цель остаётся прежней: добиться соседства.

После переполнения внешний метод AGX 1, delete_resource, освобождает IOAccelResource2, указатель на который был записан поверх uio *. Теперь повреждённый recv_msg_elem содержит указатель на освобождённую память.

Выделение свойства IOSurface замещает этот освобождённый блок базовым буфером OSData с контролируемыми атакующим байтами, организованными как поддельный uio. Закрытие обоих концов каждой пары сокетов разблокирует recvmsg_x и освобождает его объекты uio. Когда очередь доходит до повреждённого потока, uio_free() освобождает поддельный uio, оставляя OSData с висячим указателем на базовое хранилище.

Это новый, но хрупкий примитив вторичного освобождения: один объект предоставляет контролируемый первый указатель, а освобождение по этому указателю делает недействительной память, всё ещё принадлежащую другому объекту.

Эксплойт выделяет две страницы объектов IOSurfaceRootUserClient из той же зоны kalloc.512 в надежде, что один из них повторно использует висячий буфер OSData. Он читает каждое свойство через IOSurfaceCopyProperty и ищет 0x00020002 — характерный счётчик ссылок OSObject. Совпадение открывает целый действующий объект пользовательского клиента через изменяемые байты свойства.

Утёкший указатель на таблицу виртуальных функций за вычетом его несдвинутого значения из словаря смещений раскрывает сдвиг ASLR ядра.

Эксплойт копирует IOSurfaceRootUserClient, повышает его счётчик ссылок до 0x80008 и заменяет указатель по смещению 0xe0 на адрес ровно на 0xbc байта ниже глобального kernel_task. Запись изменённых байтов через висячий OSData модифицирует живой объект.

Порт задачи ядра

XNU представляет ядро как задачу, поэтому у него, как и у любой другой задачи, есть порт задачи. До iOS 10.3 право пользовательского пространства на отправку в этот порт по замыслу предоставляло произвольное чтение и запись памяти ядра.

Вызов внешнего метода IOSurface для изменённого пользовательского клиента следует по контролируемым полям и читает восемь байтов рядом с kernel_task. Эксплойт проверяет, что результат похож на указатель ядра, а затем выполняет окончательную замену объекта. Десять полей изменяются так, чтобы построить поддельный путь вызова через get_surface_use_count, внешний метод 16.

Концептуально поддельный объект заставляет диспетчеризацию внешнего метода рассматривать глобальный указатель kernel_task как задачу, связанную с новым Mach-портом. Поэтому возвращённое пользовательскому пространству имя порта является правом на отправку порту задачи ядра.

Что делать с портом задачи ядра?

Этот порт позволяет применять mach_vm_read_overwrite() и mach_vm_write() к виртуальной памяти ядра. Эксплойт обходит структуры процессов ядра, чтобы найти текущий процесс и launchd.

Каждый процесс указывает на ucred, где хранятся учётные данные POSIX UID/GID и метка MAC, описывающая его песочницу. Замена указателя ucred текущей задачи указателем из launchd предоставляет учётные данные root и снимает песочницу WebContent.

Политика платформы

Каждый процесс iOS дополнительно ограничен песочницей политики платформы. Её байт-код находится в доступной только для чтения области kext, защищённой KPP или KTRR, но объект в куче содержит изменяемый указатель на этот байт-код.

Эксплойт копирует программу политики платформы в доступную для записи память ядра, удаляет из неё хуки process-exec и process-exec-interpreter и перенаправляет указатель в куче на изменённую копию. Так не требуется изменять защищённые исполняемые или константные страницы.

Обход проверки подписи кода

Традиционные джейлбрейки часто исправляют amfid, демон Apple Mobile File Integrity. Другой путь использует динамический кеш доверия ядра — изменяемый список хешей блоков подписей кода (значений CDHash). Образы дисков разработчиков законно добавляют во время выполнения доверенные инструменты вроде lldb-server.

Операторы не отключали подпись кода глобально. Они вычисляли CDHash импланта и с помощью чтения и записи ядра добавляли в динамический кеш доверия только это значение. После этого имплант считался доверенным, а остальная политика подписи кода продолжала действовать.

Запуск импланта

Получив учётные данные root, сняв ограничения песочницы, исправив хуки выполнения политики платформы и добавив хеш импланта в доверенные, эксплойт записывает и запускает имплант. Он работает с правами root до перезагрузки и каждые шестьдесят секунд связывается со своим командным сервером, чтобы получить указания о собираемых данных.

Полные возможности импланта описаны в его подробном разборе.

Приложение A: вариант триггера

Селектор create_shmem изменился с 6 на 5 в iOS 11. Родственный вариант присутствовал в iOS 12 beta 1, но уже не воспроизводился в 12.1.1. Он воспроизводился как минимум в iOS 11.1.2, 11.3.1 и 11.4.1.

Вариант создаёт очередь команд AGX, выделяет состояние уведомлений и общей памяти, строит некорректный список дескрипторов и вызывает асинхронный внешний метод:

Большой триггер из исходного приложения также создаёт ресурсы, отображает обе общие области, заполняет счётчики дескрипторов и многократно организует кучу перед вызовом уязвимого метода AGX.

Цепочка № 3 сочетает непроверенный индекс таблицы типов в XPC с повторным IOFree в драйвере видеодекодера Apple. Первая ошибка позволяет выйти из WebContent в mediaserverd, а вторая — получить доступ к памяти ядра. Антипаттерн владения в ядре похож на цепочку № 2, но эта версия также показывает, как операторы адаптировались после удаления Apple функции mach_zone_force_gc().

Структура бинарного файла

Эксплойт динамически разрешает почти все зависимости через dlsym(), включая функции libc, Mach, IOKit, CoreFoundation и XPC:

Неиспользуемые разрешённые символы из приложения A указывают на более широкий фреймворк разработки или возможности, удалённые из этой конкретной сборки.

Непроверенный индекс массива в XPC

Словари XPC сериализуются в данные Mach-сообщений. Идентификатор проводного формата кодирует индекс типа в битах с 12-го по 20-й. Во время поиска по словарю парсер пропускает значения, пока не найдёт запрошенный ключ:

Один путь проверял, что индекс типа ненулевой и меньше _xpc_ntypes; другой путь, skip_id_and_value, передавал контролируемый атакующим идентификатор проводного формата без такой проверки. Поэтому xpc_types[wireid >> 12] читал указатель за пределами таблицы типов, а затем указатель на функцию по фиксированному смещению.

Один шанс на миллион

Первый указатель должен попасть в отображённые данные, а прочитанный из них указатель на функцию — оказаться пригодным исполняемым адресом. Общий кеш отображается с одинаковым сдвигом в нужных процессах, поэтому эксплойт может искать в его адресном диапазоне индекс типа, случайная структура которого указывает на полезный гаджет.

Локальный сканер перебирает миллионы возможных индексов, проверяет, что оба разыменования остаются внутри общего кеша, и сопоставляет сигнатуры инструкций. Он нашёл TXMLSplicedFont::~TXMLSplicedFont.

Деструктор записывает свою таблицу виртуальных функций в выбранную атакующим память, а затем следует по контролируемым полям через вложенные деструкторы. В итоге TFileDataSurrogate::~TFileDataSurrogate загружает указатель на функцию из контролируемой памяти и переходит по нему:

Сообщение

Вредоносный словарь размещает корректный элемент перед некорректным, идентификатор проводного формата которого выбирает тип за пределами массива. Объект подключения XPC вставляется напрямую, хотя обычная сериализация отвергает подключения, вложенные в сообщения. Тщательно собранные вручную байты проводного формата обходят высокоуровневый сериализатор.

Распыление кучи

Эксплойт отправляет большое количество Mach-сообщений с внестрочной памятью. Адреса общего кеша и подготовленные графы объектов повторяются по всему распылению, чтобы выбранный деструктор и последующая цепочка указателей встречали допустимые контролируемые значения.

mediaserverd

Целью служит mediaserverd — привилегированная служба, доступная отрисовщику через мультимедийные API. Её обработчик Mach принимает обычные MIG-сообщения и уведомления о мёртвых именах. Операторы организуют разбор некорректных данных XPC в этом процессе, где непроверенный индекс типа приводит к первому контролируемому косвенному вызову.

JOP2ROP

Начальный гаджет-деструктор не предоставляет сразу традиционную смену стека. Цепочка допустимых гаджетов общего кеша устанавливает регистры аргументов, перемещает SP в контролируемую память и переходит от ориентированного на переходы выполнения к обычной цепочке ROP.

Полезная нагрузка открывает из mediaserverd пользовательский клиент IOKit видеодекодера, доступ к которому в песочнице разрешён шире, чем из WebContent, и начинает этап ядра.

Повторный IOFree в ускорителе видеодекодера

В зависимости от оборудования целевым классом служит AppleVXD393UserClient или аналогичная реализация D5500. Он предоставляет методы создания и уничтожения декодеров, декодирования кадров, отображения пиксельных буферов, криптографических сеансов, получения сведений об устройстве и callback-функций.

DestroyDecoder() копирует дескриптор выделения из объекта пользовательского клиента в буфер стека и вызывает DeallocateMemory(). Последняя исключает 0x38-байтный дескриптор из двусвязного списка и освобождает его:

Флаги состояния и указатели очищались непоследовательно. Повторное уничтожение декодера использовало скопированный дескриптор снова и не один раз вызывало IOFree() для одного и того же 0x38-байтного объекта.

Эксплуатация ядра

Цель состоит в том, чтобы превратить повторное освобождение в дополнительное снятие ссылки на Mach-порт и воссоздать полезное состояние с висячим портом из цепочки № 2.

Обход последствий удаления mach_zone_force_gc

В iOS 11 явный MIG-метод удалили, но давление на память по-прежнему запускает сборку мусора зон. Эксплойт запрашивает HOST_VM_INFO64, выделяет и затрагивает немного больше всех доступных свободных страниц плюс 50 МБ, ждёт сборки мусора, а затем снимает отображение области:

Это медленнее и менее детерминированно, чем удалённый системный вызов, но восстанавливает возможность повторного использования памяти между зонами.

Подготовка кучи

Сериализация свойств IOSurface распыляет 0x38-байтные базовые выделения OSData. Эксплойт освобождает один дескриптор декодера, затем отправляет дескриптор внестрочных портов с семью именами, который также создаёт в ядре 0x38-байтный буфер.

Запуск повторного освобождения высвобождает память, которая теперь принадлежит другому объекту.

Утечка указателей

Чтение свойств IOSurface раскрывает байты замещающих объектов. Помеченные значения определяют перекрывающее выделение и раскрывают указатели ядра, необходимые для последующих поддельных структур.

От повторного освобождения к лишнему снятию ссылки на порт

Замещающий дескриптор внестрочных портов содержит ссылки на целевой порт. Когда его буфер освобождается так, словно это устаревший дескриптор VXD, владение становится несогласованным. Позднее очистка Mach-сообщения перебирает его элементы и вызывает ipc_object_destroy() для каждого допустимого указателя, снимая ссылки, которыми по-прежнему рассчитывает владеть обычный жизненный цикл сообщения.

Третье замещение

После создания висячего целевого порта третье распыление замещает его хранилище контролируемым OSData. Первые два поля содержат известный адрес целевого порта в ядре, а остальная часть имеет форму поддельных ipc_port и задачи.

Объединение цепочек

Пользовательская ошибка XPC предоставляет выполнение кода в mediaserverd; этот процесс может открыть пользовательский клиент VXD. Повторное освобождение VXD вызывает межзонное повреждение, раскрывает указатели и создаёт висячий Mach-порт. Поддельный порт предоставляет те же примитивы pid_for_task, KASLR и поддельного порта задачи ядра, которые были разработаны в цепочке № 2.

Полный поток выглядит так:

Действия после эксплуатации

Получив чтение и запись памяти ядра, эксплойт находит launchd, заимствует его учётные данные для снятия ограничений песочницы, исправляет политику выполнения и добавляет CDHash импланта в кеш доверия. Он запускает имплант и по возможности восстанавливает исходные учётные данные процесса.

Общий для цепочек имплант описан в разборе импланта.

Приложение A: неиспользуемые разрешённые символы

Бинарный файл разрешает множество функций, которые не используются в наблюдаемом пути, включая коллекции и потоки CoreFoundation, операции с файловой системой, запись по FTP, API событий HID, приостановку задач, вызовы памяти Mach и обнаружение IOKit. Вероятно, это след многократно используемого фреймворка эксплойтов, а не функциональность, необходимая только цепочке № 3.

Выход из песочницы снова связан с XPC: на этот раз демон без песочницы неверно управляет временем жизни объекта XPC. Ошибка ядра исключительно прямолинейна: внешний метод IOKit начинается с неограниченного memmove(), длину которого задаёт вызывающая сторона.

Начинаем с _start

Как и в цепочке № 3, бинарный файл повышения привилегий самостоятельно разрешает символы, а не полагается на обычный импорт Mach-O. Он завершает остальные потоки задачи и проверяет, не выполнялась ли эксплуатация ранее.

Предыдущие цепочки записывали маркер в аргументы загрузки ядра. Эта вместо него использует менее навязчивый маркер в видимом процессам состоянии, чтобы повторный запуск мог остановиться без изменения строки загрузки.

Снова XPC

Цепочка № 4 содержит отдельные выход из песочницы и эксплойт ядра. Слабость XPC находится не в основном сериализаторе, а в ошибочной логике владения внутри демона.

Управление временем жизни объектов в XPC

Объекты XPC — это Objective-C-объекты со счётчиком ссылок. Контейнеры удерживают свои элементы; xpc_retain() и xpc_release() изменяют владение. Асинхронный API должен гарантировать, что объекты и блоки ответа остаются живы до завершения всех возможных путей выполнения.

Обработка вложенных запросов особенно хрупка: если и вложенное сообщение, и внешний словарь владеют одним объектом или освобождают его, пропущенная callback-функция может оставить один путь в уверенности, что владение было передано, пока другой путь уничтожает объект.

Уязвимость cfprefsd

com.apple.cfprefsd.daemon — служба XPC, размещённая в cfprefsd. Она работает без песочницы с правами root и доступна как из песочницы приложений, так и из WebContent. Бинарный файл в основном представляет собой заглушку, переходящую к __CFXPreferencesDaemon_main в CoreFoundation.

Демон создаёт параллельный слушатель XPC и распределяет входящие сообщения по обработчикам конкретных операций. Один запрос может содержать массив вложенных сообщений. Обработка удерживает состояние ответа, вызывает обработчик для каждого вложенного сообщения и ожидает, что его блок завершения уравновесит владение.

Один из путей обработчика не вызывал свой блок ответа. Очистка освобождала коллекцию вложенных сообщений, уничтожая xpc_dictionary, тогда как внешний запрос всё ещё содержал и позднее освобождал тот же указатель. Интервал между этими освобождениями создаёт окно использования после освобождения.

Эксплуатация Поток выполнения эксплойта

Гонку координируют четыре потока. Потоки A, B и C ждут глобального флага, а затем каждый отправляет по сто заполняющих аллокатор XPC-сообщений. Главный поток отправляет триггер и открывает окно гонки между уничтожением массива вложенных сообщений и освобождением внешнего запроса.

Сообщения участников гонки повторно заполняют освобождённый словарь значением указателя 0x118080000 — адресом, выбранным для поддельного класса Objective-C и графа кеша селекторов.

Сообщение-триггер

Триггер использует операцию 4, обрабатываемую handleFlushSourceForDomainMessage, потому что её путь ошибки не вызывает ожидаемый блок ответа. Внешний словарь содержит вложенный запрос и вспомогательные ключи, необходимые для достижения этой последовательности очистки.

Управление PC

xpc_release() рассматривает первое двойное слово как isa Objective-C. Если оно указывает в область известных классов libxpc, функция использует os_object_release; в противном случае она вызывает objc_release. Замещающее значение находится за пределами области libxpc, поэтому диспетчеризация Objective-C следует по поддельному классу.

Техника поддельного кеша селекторов

objc_msgSend следует по isa к объекту класса, а затем к кешу селекторов, содержащему пары (function pointer, selector). Поддельный элемент кеша для release предоставляет управление PC при освобождении устаревшего объекта.

Полный контроль

При первом получении управления PC регистр X0 указывает на освобождённый словарь. В iOS 12 усилили longjmp, в том числе на устройствах до A12 без PAC, поэтому прежняя прямая смена стека больше не работает. Операторы используют последовательность JOP-гаджетов, чтобы установить контролируемые регистры и состояние стека, а затем перейти к обычной цепочке ROP.

Полезная нагрузка открывает ProvInfoIOKitUserClient в процессе cfprefsd с правами root и отправляет полученное подключение обратно исходному процессу в песочнице.

Уязвимость ядра

ProvInfoIOKitUserClient существует как минимум с iOS 10 и предоставляет шесть внешних методов через getTargetAndMethodForIndex. Метод 5, ucEncryptSUInfo, принимает и возвращает структуры размером ровно 0x7d8 байта; IOUserClient::externalMethod проверяет эти размеры верхнего уровня.

Первая операция метода фактически выглядит так:

Размеры входного и выходного выделений ограничены, но смещение и длина контролируются атакующим. Поэтому один запрос может читать за пределами своего буфера запроса в ядре и записывать за пределы буфера ответа.

Эксплуатация ядра

Эксплойт определяет смещения конкретной сборки, открывает IOSurfaceRootUserClient для распыления OSData, повышает лимит файлов, создаёт 0x800 каналов и выделяет 1024 ранних порта. Четыре группы ещё по 768 портов формируют контролируемые блоки ipc.ports.

Массивы внестрочных портов и дескрипторы внестрочной памяти создают чередующиеся выделения kalloc.4096. Желаемый шаблон представляет собой последовательность контролируемых буферов указателей на порты и пустых 4096-байтных буферов:

Выбранные буферы портов освобождаются для создания пустот:

Тот же метод применяется к kalloc.6144: объекты OSData размером 4104 байта, заполненные ASCII-символами 1, чередуются с пустыми выделениями внестрочной памяти.

Создание пустот

У выбранных 4096- и 6144-байтных выделений уничтожается средняя половина. Сложная схема из 24 выделений заполняет лишь часть освобождённого пространства. Затем атакующий вызывает уязвимый метод, размещая его объекты запроса и ответа ipc_kmsg внутри этих пустот.

Получение в EL1

Внешний метод выполняется в контексте ядра. При успешном расположении его memmove увеличенного размера читает за пределами запроса из соседнего буфера внестрочных портов и записывает эти байты за пределами ответа в базовый буфер распылённого OSData.

Чтение всех свойств IOSurface обратно в пользовательское пространство раскрывает возможные указатели ядра. Допустимый указатель определяет адрес целевого Mach-порта в ядре.

Повторять до успеха

Второй триггер использует новые схемы размещения 4096- и 6144-байтных объектов.

Эксплойт снова создаёт пустоты:

4096-байтный буфер внестрочной памяти содержит два известных указателя на порты. Чтение за пределами буфера затягивает их в данные запроса, а запись за пределами буфера копирует их в соседний дескриптор внестрочных портов. Для этих записанных указателей ссылки не получались, поэтому теперь дескриптор содержит удерживающие ссылки значения, о которых не знает его учёт владения.

Путь к поддельному порту задачи ядра

В отличие от предыдущих цепочек, эксплойт не уничтожает повреждённое сообщение внестрочных портов немедленно. Он уничтожает своё обычное право на отправку в target_port, и указатель внутри поставленного в очередь дескриптора остаётся единственным путём к теперь уже висячему ipc_port.

После уничтожения окружающих групп портов и принудительной сборки мусора зон посредством давления на память исходная задача больше не имеет висячего имени в своём пространстве имён. Но ей по-прежнему принадлежит право на получение Mach-сообщения с повреждённым дескриптором. Более позднее получение этого сообщения импортирует указатель и воссоздаёт право на отправку висячему порту.

Это важное различие: поставленное в очередь сообщение служит долговременным хранилищем ссылки, которую после межзонного замещения можно снова преобразовать в имя пользовательского пространства.

Порты в каналах

Освобождённая страница ipc_port напрямую замещается изменяемыми буферами каналов с поддельными структурами порта и задачи. Маркер контекста определяет нужный канал и смещение. Чтение и перезапись этого канала изменяют живой поддельный порт без повторного выделения его базовой памяти.

Затем цепочка снова использует примитив чтения pid_for_task и создание поддельного порта задачи ядра, разработанные в цепочках № 2 и № 3. Получив чтение и запись ядра, она заимствует учётные данные launchd, исправляет политику выполнения платформы, добавляет CDHash импланта в динамический кеш доверия, запускает имплант и по возможности восстанавливает состояние процесса.

Имплант описан в разборе импланта.

У операторов уже были работающие уязвимости нулевого дня из цепочки № 4, однако они перешли на этот эксплойт. Вероятными причинами стали надёжность и простота: одна уязвимость заменила цепочку из нескольких ошибок и позволила избежать нестабильной гонки повторного выделения XPC на основе потоков.

Ещё удивительнее сама ошибка. Apple добавила незавершённую функцию ваучеров в iOS 8 в 2014 году. По всей видимости, её новый MIG-метод порта задачи никогда не работал правильно. Обычный вызов с ожидаемыми аргументами вызвал бы панику ядра. Дефект сохранялся около четырёх лет и в итоге стал применяться для массовой эксплуатации.

Ваучеры

Ваучеры Mach представляют наборы атрибутов, которые можно передавать между процессами через право отправки Mach. Объект ядра ipc_voucher содержит счётчик ссылок, таблицу атрибутов и указатель на ipc_port, представляющий его пользовательскому пространству.

Предполагаемый контракт владения уязвимого метода описан в статье voucher_swap: эксплуатация подсчёта ссылок MIG в iOS 12. MIG передаёт new_voucher как заимствованную ссылку и передаёт методу владение входным old_voucher; при успешном выполнении метод должен вернуть старый ваучер во владение вызывающей стороне.

Реализация-заглушка лишь перезаписывала указатель ввода-вывода:

Она не освобождала входной старый ваучер и не увеличивала счётчик ссылок заимствованного нового ваучера. Позже обёртка освобождала и преобразовывала значения в соответствии с семантикой MIG, что предоставляло атакующим как утечки ссылок, так и их сбрасывание.

Первопричина может быть неочевидна читателям, незнакомым с MIG, но обнаружить сбой элементарно: достаточно создать ваучеры и вызвать метод. Это была не теоретическая слабость, а активно эксплуатируемая уязвимость.

Эксплуатация

Объект ipc_voucher выделяется из зоны и указывает на порт ваучера. Эксплойт с помощью примитива сбрасывания ссылок освобождает ваучер, на который всё ещё остаются ссылки в приостановленном потоке. Затем сборка мусора зон позволяет повторно использовать его страницу для выделений другого класса.

Стратегия эксплуатации

Эксплойт определяет размер страниц — 4 КиБ или 16 КиБ — через hw.memsize, создаёт приостановленный поток и сохраняет его порт. Он увеличивает ограничение на количество файловых дескрипторов и создаёт 0x800 каналов.

Кроме того, он выделяет:

• Две большие группы портов, ports_a и ports_b.

• Два отдельных целевых порта.

• Один ваучер ATM, зарезервированный для конца эксплуатации.

• 0x2000 уникальных ваучеров ATM до цели.

• Целевую группу ваучеров и группу после неё, окружающие жертву.

Давление на память запускает сборку мусора зон. Группы ваучеров должны разместить цель во фрагменте, содержащем только подконтрольные атакующему объекты ipc_voucher.

Целевой ваучер устанавливается в приостановленном потоке. task_swap_mach_voucher вызывается в комбинациях, которые сбрасывают ссылки, не удаляя указатель потока. Уничтожение окружающих ваучеров опустошает фрагмент, и сборщик мусора под давлением памяти возвращает его в общий пул зон.

Дескрипторы внестрочной памяти замещают освобождённую страницу ваучера управляемыми байтами. Вызов thread_get_mach_voucher() через висячий указатель интерпретирует эти байты как ipc_voucher, увеличивает поддельный счётчик iv_refs и преобразует поддельный iv_port в право отправки пользовательского пространства.

Эксплойт выделяет 0x2000 портов discloser_before_ports, один соседний целевой порт с контекстом 0x1337733100 и соответствующие порты после него. Дескрипторы OOL принимаются до тех пор, пока один из них не будет содержать правдоподобный указатель ядра и iv_refs == 0x101: распыление установило его в 0x100, а создание порта ваучера добавило единицу.

Соответствующий буфер раскрывает адрес ядра. Перед повторным использованием дескриптора эксплойт перемещает iv_port на следующую страницу размером 16 КиБ. Исходная поддельная ссылка на порт ваучера не позволила бы опустошить фрагмент зоны и выполнить сборку мусора; смещение указателя нацеливает его на страницу, которую можно повторно выделить в другой зоне.

Теперь у эксплойта есть обе предпосылки для чтения и записи памяти ядра:

1. Управляемый указатель, интерпретируемый как ipc_port.

2. Известный адрес ядра, по которому могут попасть управляемые данные распыления.

Каналы

Буферы 0x800 каналов содержат поддельные порты pid_for_task. Поскольку известно, что iv_port указывает на границу 4 КиБ, каждый поддельный порт занимает нижнюю половину буфера канала. По смещению +0x800 в буфере записан индекс канала, а поддельная задача организована так, чтобы pid_for_task() прочитала этот маркер.

Эксплойт вызывает thread_get_mach_voucher(), чтобы получить право отправки поддельному порту, затем вызывает pid_for_task() и по возвращённому маркеру определяет успешный канал. Чтение и перезапись этого канала изменяют поддельную задачу и порт по известному адресу ядра.

Далее создаётся стандартный примитив:

Выход из песочницы

Эксплойт проходит по списку allproc, чтобы найти собственный процесс и launchd. Он временно присваивает текущему процессу учётные данные launchd, наследуя его идентификатор root и профиль песочницы.

Затем он:

1. Исправляет доступную для записи копию или указатель байт-кода политики платформы в песочнице.

2. Читает встроенный имплант из __DATA,__file.

3. Вычисляет его CDHash и добавляет его в динамический кеш доверия.

4. Записывает бинарный файл в /tmp/updateserver.

5. Запускает его через posix_spawn().

6. Помечает устройство как скомпрометированное, устанавливая kern.maxfilesperproc в 0x27ff.

Имплант исследован в статье «Разбор импланта».

Очистка

Поддельный порт задачи ядра уничтожается. Его искусственный счётчик ссылок равен 0x2000, поэтому память нижележащего канала неожиданно не освобождается. Все дескрипторы каналов закрываются, и эксплойт завершает работу.

Наконец, он обращается к конечной точке HTTP, чтобы сообщить об очередной успешной компрометации. Имплант продолжает работать с правами root и запускает цикл опроса сервера управления.

Эксплойты используют общую архитектуру:

1. Активировать ошибку JavaScriptCore.

2. Создать addrof и fakeobj через путаницу между double и JSValue.

3. Построить поддельный объект JavaScript для чтения и записи памяти.

4. Обойти ограничения записи JIT и внедрить шелл-код.

5. Выполнить соответствующую полезную нагрузку повышения привилегий.

Новые ошибки подключались к в основном стабильной инфраструктуре эксплуатации. Некоторые могли быть уязвимостями нулевого дня, а другие, вероятно, использовались в промежутке между публичным исправлением WebKit и его доставкой пользователям iOS.

Например, 9 февраля 2019 года WebKit публично исправил CVE-2019-8518 в HEAD репозитория и добавил регрессионный тест, демонстрировавший доступ к JSArray за границами. Пользователи iOS получили патч лишь 25 марта в iOS 12.2, примерно через шесть недель. Оператору с готовой инфраструктурой могут потребоваться считаные дни для замены активации.

Другие разработчики иначе обращались с этим разрывом. Chromium исторически публиковал JavaScript PoC вместе с исправлениями, хотя в некоторых новых патчах их уже не было. Microsoft сохраняла изменения безопасности Chakra закрытыми до выпуска. Mozilla обычно удерживала исправления почти до следующего релиза и избегала публикации активирующего JavaScript.

Эксплойт 1: iOS 10.0–10.3.2

Первый эксплойт нацелен на CVE-2017-2505, о которой lokihardt сообщил как о проблеме Project Zero 1137. WebKit исправил её в HEAD 11 марта 2017 года, но пользователи получили iOS 10.3.2 только 15 мая, более чем через два месяца.

Активация из реальной атаки почти полностью совпадает с тестом, опубликованным вместе с патчем.

Ошибка смешивает представления хранилища массивов. Эксплойт превращает повреждение в перекрывающиеся массивы double и объектов, а затем создаёт обычные примитивы получения адреса, поддельного объекта и TypedArray.

Эксплойт 2: iOS 10.3–10.3.3

Этот эксплойт, по-видимому, нацелен на CVE-2017-7064 или её вариант, зарегистрированный lokihardt как проблема 1236. WebKit исправил её 18 апреля 2017 года; iOS 10.3.3 вышла 19 июля, оставив трёхмесячное окно.

Неинициализированная память трактуется как содержимое массива JavaScript. Подготовка кучи управляет этой памятью и создаёт путаницу между double и JSValue. Операторы строят addrof и fakeobj, а затем подделывают TypedArray для произвольного чтения и записи.

Эксплойт 3: вероятно, iOS 11.0–11.3

Эксплойт нацелен на ошибку WebKit 181867, возможно CVE-2018-4122. Её исправили в HEAD 19 января 2018 года, и, вероятно, она дошла до пользователей с iOS 11.3 29 марта.

Первопричина — ошибка моделирования побочных эффектов JIT. Оптимизированный код предполагает, что операция не изменяет состояние массива, тогда как обратный вызов или приведение типа делает это. Неупакованные double и упакованные значения перекрываются, снова создавая addrof, fakeobj и поддельный TypedArray.

Эксплойт 4: вероятно, iOS 11.3–11.4.1

Эксплойт нацелен на проблему WebKit 185694, исправленную 16 мая 2018 года и, вероятно, выпущенную в iOS 11.4.1 9 июля. Это ещё одна ошибка побочных эффектов JIT.

К этому времени Gigacage защищала внутренние буферы ArrayBuffer, поэтому одного поддельного TypedArray уже было недостаточно. Сначала эксплойт создаёт поддельный неупакованный массив double для ограниченного примитива чтения и записи, с его помощью отключает Gigacage, а затем возвращается к TypedArray для остальной инфраструктуры.

Эксплойт 5: iOS 11.4.1

Эксплойт нацелен на CVE-2018-4438, зарегистрированную как проблема 1649. WebKit исправил её 26 октября 2018 года; iOS 12.1.1 с патчем вышла 5 декабря.

JavaScriptCore разрешал массив с неожиданным прототипом Proxy. Ловушка прокси выполняет изменения с побочными эффектами, пока JIT-код предполагает их отсутствие, создавая тот же общий класс эксплуатации. Цепочка получает ограниченное чтение и запись массива, отключает Gigacage и переходит к TypedArray для полного доступа к памяти.

Эксплойт 6: вероятно, iOS 12.0–12.1.1

Эксплойт нацелен на CVE-2018-4442, зарегистрированную как проблема 1699. Она была исправлена в HEAD 17 октября 2018 года и выпущена в iOS 12.1.1 5 декабря.

В отличие от предыдущих ошибок JIT, это использование после освобождения в JavaScriptCore. Эксплойт освобождает хранилище свойств объекта, называемое butterfly, а затем многократно вызывает Function.bind(), чтобы массив JSBoundFunction.m_boundArgs занял освободившуюся память.

Загрузка свойства через устаревший butterfly раскрывает внутренний объект связанных аргументов. Преобразование массива в разреженный и вызов функции достигает JSBoundFunction::boundArgsCopy, которая предполагает плотность m_boundArgs и читает JSValue за границами буфера в аргументы контролируемой функции.

Операторы превращают OOB-доступ в addrof и fakeobj, а затем снова используют готовую инфраструктуру.

Эксплойт 7: iOS 12.1.1–12.1.3

Последний эксплойт нацелен на ту же ошибку, что использовал WebKit RegEx exploit Линуса Хенце, по-видимому проблему WebKit 191731 и, возможно, CVE-2019-6217. Исправление появилось 16 ноября 2018 года и вышло в iOS 12.1.3 22 января 2019 года.

Это ещё одна ошибка моделирования побочных эффектов JIT. Вместо объектов WebAssembly Хенце операторы подключают активацию к старой инфраструктуре, создают поддельный массив JavaScript для первоначального доступа к памяти, отключают нужные средства защиты и продолжают теми же примитивами TypedArray.

Выполнение шелл-кода

Каждый эксплойт одинаково переходит от чтения и записи памяти к машинному выполнению. В iOS 10 Apple представила «пуленепробиваемый JIT»: исполняемые страницы JIT нельзя записывать через обычное отображение, а второе скрытое отображение позволяет копировать сгенерированный код.

Архитектуре неизбежно нужен доверенный путь jit_memcpy. Атакующий с примитивом управления потоком может вызвать его с контролируемым шелл-кодом даже без прямого доступа к доступному для записи псевдониму.

Эксплойт создаёт JOP-цепочку из трёх гаджетов, вызывающую произвольную функцию с контролируемыми аргументами. Указатель нативной функции JavaScript escape заменяется первым гаджетом. Затем цепочка вызывает jit_memcpy, перезаписывая JIT-код уже скомпилированной функции шелл-кодом, и ещё раз меняет escape, направляя её на внедрённый код.

Устройства A12 добавляют защиту JIT на основе PAC, подписывающую сгенерированный код и позднее проверяющую его. Ни один восстановленный эксплойт процесса отрисовки не обходил механизм: они обнаруживали A12 и завершались.

Полученный шелл-код запускает один из пяти локально описанных этапов повышения привилегий, начиная с цепочки эксплуатации iOS № 1.

Некоторые приложения используют это значение для авторизации. Служб Windows от самой Microsoft с таким поведением найти не удалось, но существуют сторонние примеры, включая антивирус Check Point. PID нельзя считать надёжным удостоверением личности. В статье описано несколько способов его подмены, чтобы разработчики не использовали его как границу безопасности, а исследователи могли эксплуатировать небезопасные проверки.

Уязвимый сервер может выглядеть так:

Ошибка заключается в том, что метаданные, записанные при установлении соединения, считаются доказательством того, какой процесс сейчас выполняет операции.

Откуда берётся PID?

Именованные каналы реализованы в NPFS. Когда клиент открывает канал, запрос создания может включать буфер расширенных атрибутов (EA), содержащий метаданные соединения: PID клиента, идентификатор сеанса и имя компьютера.

Если запрос приходит из UserMode, NPFS не доверяет переданным вызывающей стороной атрибутам соединения и записывает текущий процесс. Если IRP.RequestorMode == KernelMode, NPFS разрешает использовать EA, поскольку компонентам ядра, например серверу SMB, необходимо представлять идентификационные данные удалённого клиента.

Концептуально это выглядит так:

Значение хранится в соединении канала и не меняется динамически вслед за процессом, который владеет клиентским дескриптором или использует его.

Способы подмены

Все способы проверены в Windows 10 1903. У каждого есть практические ограничения.

Открытие канала через локальный SMB и точку подключения NTFS

Защиту NPFS можно обойти с помощью инициатора режима ядра. До CVE-2018-0749 произвольная локальная точка подключения NTFS могла перенаправить открытие файла SMB на любое устройство, в том числе NPFS. SMB принимает управляемые вызывающей стороной EA и открывает цель из режима ядра, поэтому NPFS доверяла поддельным значениям PID и сеанса.

CVE-2018-0749 ограничила такое перенаправление. Однако в Windows 10 1709 обработку точек подключения изменили, разрешив повторный разбор пути не только в обычные тома файловой системы, но и в устройства именованных каналов. Локальный клиент по-прежнему может объединить:

1. Точку подключения NTFS, целью которой служит путь NPFS.

2. Локальное открытие SMB через эту точку подключения.

3. Буфер EA с произвольными метаданными клиента именованного канала.

Структурно пример проверки концепции на основе NtApiDotNet выглядит так:

Если EA не передан, NPFS записывает процесс сервера SMB. Поскольку он работает от имени System, видимый PID клиента становится равен 4. Это менее полезно, чем возможность напрямую выбрать любое значение.

Требования существенны: локальный SMB должен быть включён и доступен, вызывающая сторона должна создать или контролировать подходящую точку подключения, а конфигурация цели должна разрешать перенаправление.

Открытие канала через локальный SMB

В старых системах до Windows 10 1709 нельзя использовать вариант с точкой подключения, но обычное открытие \\localhost\pipe\ABC всё равно заставляет SMB передать атрибут PID клиента.

Это значение не является настоящим идентификатором локального процесса. Windows 10 1903 записывает 65279 (0xFEFF), взятое из заголовка SMB2. В документации Microsoft по протоколу соответствующие четыре байта названы зарезервированными и сказано, что сервер может их игнорировать. Wireshark обозначает это поле понятнее: Process ID со значением по умолчанию 0xFEFF.

Так можно подменить идентификатор на фиксированный, но не на произвольный. Этого всё равно может быть достаточно, чтобы обойти службу, которая отличает лишь один доверенный PID или разрешает доступ при ошибке поиска процесса.

Атакующий мог бы реализовать достаточную часть SMB2, чтобы выбирать значение заголовка, но на практике ему помешают аутентификация и доступ к localhost. Песочницы AppContainer обычно не могут обращаться к локальному SMB или получать подходящие учётные данные.

Открытие канала в одном процессе и использование в другом

Последний способ не зависит от SMB. Он использует тот факт, что NPFS записывает PID только один раз — при открытии клиентского соединения. Читать или записывать данные позже может уже другой процесс.

Процесс A открывает канал с наследуемым дескриптором, создаёт наследующий его процесс B и завершается. Записанный NPFS идентификатор по-прежнему относится к A. Атакующий создаёт процессы, пока Windows не использует PID процесса A повторно для доверенного исполняемого файла или выбранного процесса. Затем процесс B использует унаследованный канал, а сервер видит повторно назначенный PID.

Этот способ работает, только если сервер проверяет PID после первоначального чтения или записи. Если авторизация выполняется сразу внутри обратного вызова соединения, исходный процесс ещё работает и его PID пока не использован повторно.

Для повторного использования PID также необходимо создать достаточно процессов, чтобы прокрутить распределитель, и достаточно хорошо управлять временем, чтобы устаревшее значение получил нужный процесс.

Выводы

GetNamedPipeClientProcessId сообщает метаданные соединения, а не криптографически подтверждённые идентификационные данные и не обязательно процесс, который сейчас использует дескриптор. На значение можно повлиять через доверенные посредники ядра, установить его из заголовка SMB или сохранить при наследовании дескриптора и повторном использовании PID.

Серверы именованных каналов должны аутентифицировать клиентов с помощью предназначенных для авторизации механизмов: олицетворять клиента канала и исследовать его токен, применять списки управления доступом к каналу, проверять криптографические учётные данные в протоколе либо дублировать и проверять дескриптор процесса в момент, когда ядро гарантирует связь.

Разработчики никогда не должны разрешать привилегированные операции только потому, что PID клиента именованного канала якобы указывает на доверенный процесс.

Зрелые программы с историей выпусков с 1990-х предлагают другой ресурс: старые версии и сборки для больше не поддерживаемых платформ. Основной код может меняться медленно, поэтому вспомогательная информация из исторических пакетов остаётся актуальной для современных выпусков. Ранняя разведка способна сэкономить значительные усилия позднее.

Отладочные символы Adobe Reader

Символы могут раскрывать имена функций и перечислений, исходных файлов, прототипы, структуру объектов и типы. Даже простые имена функций облегчают чтение ассемблера и превращают адреса сбоев в содержательные трассировки стека.

Microsoft Visual C++ обычно записывает символы Windows во внешние файлы .pdb. Adobe, по-видимому, не поставляла соответствующие PDB для исполняемых файлов и библиотек Reader. Старых встроенных символов DBG также не нашлось.

Форматы семейства Unix могут встраивать символы прямо в двоичные файлы, повышая вероятность их случайной или намеренной публикации. Adobe поставляла такую информацию в компонентах Reader более двадцати лет. Этот факт был известен некоторым исследователям, но заслуживал широкой документации.

Я собрал пакеты Reader начиная с версии 3.x и изучил часто атакуемые компоненты:

• acroread, основное приложение;

• AGM, Adobe Graphics Manager;

• CoolType, типографический движок;

• BIB, Bravo Interface Binder;

• JP2K, библиотеку JPEG 2000;

• rt3d, среду выполнения 3D.

Когда-то Adobe выпускала Reader для SunOS, IRIX, OSF/1, HP-UX, AIX и Linux. Исторические пакеты сохранились на HTTP/FTP-серверах Adobe и в Internet Archive. Среди этих выпусков каждый основной модуль хотя бы однажды поставлялся с символами.

Поддержка Unix завершилась Reader 9.5.5 в 2013 году. Новейшие публичные символы CoolType датировались 2005-м, а остальные компоненты имели сборки с символами 2013 года. Даже старая информация CoolType оставалась полезной в 2015 году при анализе интерпретатора OpenType CharString.

Дополнительные сборки с символами предоставляла macOS. Пакеты Reader 7.x, 8.x, 9.x и DC содержали отладочную информацию основных компонентов, а не только JP2K и 3D, как считалось изначально.

Практическое применение символов

Исторические символы ускоряют восстановление архитектуры и фаззинг. Есть два основных процесса:

1. Проверять или фаззить старый двоичный файл с символами, а затем воспроизводить находки в современной версии.

2. Перенести имена и типы из старого файла в текущую цель и работать непосредственно с поддерживаемым выпуском.

Второй способ избегает различий, вызывающих ложноположительные или ложноотрицательные результаты, но автоматическое сопоставление разных дат, платформ и компиляторов сложно. BinDiff и Diaphora помогают, но несовершенны.

Практический компромисс — параллельный анализ в IDA. Переименовываются только функции и объекты, относящиеся к текущему исследованию. Полная библиотека может содержать тысячи функций, а одна ошибка затрагивает небольшое подмножество. Со временем IDB накапливает полезные имена, которые легко переносить через небольшие изменения Patch Tuesday.

Пример JP2K

Проблема Project Zero 1892 представляла собой повреждение кучи в JP2KLib.dll. Изначально WinDbg показывал главным образом смещения; имя имела только экспортируемая JP2KImageDecodeTileInterleaved.

Сбой не воспроизводился в macOS, но Mach-O AdobeJP2K всё равно служил справочником. Откроем модули Windows и macOS рядом в IDA и начнём с общей экспортируемой точки входа.

Первую совпадающую вызываемую функцию можно переименовать из sub_1004DC58 в IJP2KImage::DecodeTile с mangled-именем:

Следование по вызовам выявляет вторую перегруженную реализацию DecodeTile, а затем более глубокий путь сбоя. Одна функция верхнего уровня была встроена компилятором macOS, поэтому её пришлось определять по libJP2K.so Linux с символами.

После переноса нужных имён отладчик IDA с серверной частью WinDbg даёт полезную трассировку:

Несколько инструментов заявляют об экспорте имён IDA в совместимые с WinDbg символы, но испытанные варианты были неполными, самодельными, склонными к ошибкам или требовали исправлять исходный код. Отладка в IDA осталась самым надёжным процессом.

Пример CoolType

Второй сбой находился в CoolType. Исходный стек снова почти полностью состоял из смещений без очевидной экспортируемой начальной функции.

Ручной анализ ассемблера и знакомство со шрифтовыми движками позволили определить CoolType!CTInit+0x460e1 как интерпретатор OpenType CharString, который в исторических сборках назывался DoType1InterpretCharString.

После нахождения одной опорной точки вызывающие и вызываемые функции можно сопоставить с несколькими независимыми источниками символов:

• CoolType из Reader 4 и Reader 5;

• символами DWrite и fontdrvhost.exe Microsoft;

• символами libType1Scaler.dylib Apple.

Эти компоненты используют значительный объём общего кода обработки OpenType. Следование по графу восстановило большую часть верхнего стека, включая ATMBuildBitMap и функции интерпретатора CharString.

Функции выше ATMBuildBitMap переименовать не удалось: косвенный вызов прерывал трассу, а узнаваемого предка не было. Но даже восьми имён верхнего уровня хватило, чтобы понять, какая подсистема неправильно обработала повреждённый шрифт и как выполнение дошло до исключения.

Уроки

Перенос символов никогда не гарантирован. Код меняется, компиляторы по-разному встраивают и переставляют его, платформы используют разные ABI, а сравнение двоичных файлов несовершенно. Но исторические метаданные способны убрать дни однообразного обратного анализа.

Сам поиск полезен: старые архивы разработчиков, малоизвестные установщики, снятые с поддержки пакеты Unix и сборки с символами для других ОС могут содержать ровно тот контекст, которого не хватает современной цели.

Прежде чем считать закрытый двоичный файл полным чёрным ящиком, изучите историю выпусков. Возможно, разработчик непреднамеренно задокументировал современную кодовую базу много лет назад на другой платформе.

16 июня я обнаружил, что SoC A11 в iPhone 8 и iPhone X предоставляет регистры внешней отладки CoreSight. В сочетании с проприетарными средствами управления DBGWRAP эти регистры позволяют отлаживать CPU в любой момент, включая выполнение вектора сброса после пробуждения и до восстановления MMU и KTRR.

Пошаговое выполнение вектора сброса и изменение состояния регистров на ключевых инструкциях позволяют пропустить блокировку KTRR в MMU и повторно отобразить защищённую память ядра с правом записи. Так появился KTRW — одношаговый отладчик ядра iPhone X аппаратного уровня, совместимый с LLDB и IDA Pro и работающий через обычный кабель Lightning.

Проблема начальной загрузки

Исследовать iPhone сложнее, чем должно быть. Надёжная безопасность платформы полезна пользователям, но заставляет исследователей создавать и поддерживать дорогостоящие исследовательские платформы.

Это создаёт неверные стимулы. Исследователи могут сохранять уязвимости для начальной загрузки вместо того, чтобы сообщать о них, хотя атакующие способны применять те же ошибки как уязвимости нулевого дня. Другие используют инженерные устройства с доступом SWD/JTAG к процессору приложений, Secure Enclave, AOP и периферии. Остановка загрузчика позволяет исправить ядро до инициализации мер защиты.

Другой путь предоставляют виртуализированные устройства, но размещённые у провайдера системы могут раскрывать ему конфиденциальные эксперименты. Я не хотел скрывать ошибки, использовать инженерное оборудование или проводить неопубликованные исследования уязвимостей на сторонних серверах.

KTRR и другие аппаратные меры защиты

Вероятно, KTRR означает область текста ядра только для чтения (Kernel Text Readonly Region). Это аппаратный механизм W^X, реализованный как в MMU каждого CPU, так и в контроллере памяти Apple, который в открытых исходниках XNU называется AMCC.

MMU использует три системных регистра Apple:

• KTRR_LOWER_EL1

• KTRR_UPPER_EL1

• KTRR_LOCK_EL1

Первые два задают физический диапазон. Запись 1 в регистр блокировки навсегда замораживает все три регистра до сброса ядра. После активации MMU вызывает ошибки при записи в эту область и при извлечении инструкций EL1 за её пределами независимо от разрешений таблицы страниц или APRR.

AMCC независимо отбрасывает записи в свой защищённый физический диапазон. Это не позволяет DMA и периферии обходить MMU процессора.

Критические ресурсы, включая корень таблицы страниц и таблицы страниц, описывающие защищённый текст, находятся внутри защищённого диапазона. Инструкции, способные отключить трансляцию или заменить TTBR1_EL1, расположены в __LAST.__pinst — за пределами исполняемой KTRR-области MMU, но внутри доступной только для чтения KTRR-области AMCC. После блокировки их нельзя ни исполнить, ни изменить.

После пробуждения ядра LowResetVectorBase настраивает и блокирует KTRR примерно в пределах первых ста инструкций. Обход должен вмешаться в этот узкий путь сброса.

Цели для исследовательского iPhone

Желаемая платформа должна:

1. Исправлять защищённую KTRR секцию __TEXT_EXEC и при необходимости отключать другие меры защиты.

2. Пошагово выполнять код ядра и позволять исследовать регистры и память.

3. Работать с разными версиями iOS без повторного построения полной цепочки эксплойтов.

4. Интегрироваться с LLDB или другим стандартным отладчиком.

5. Быть сопровождаемой и пригодной для обычного розничного оборудования.

iOS 10.1.1: обход KTRR в Yalu

Обход Yalu Луки Тодеско сочетал сохранение состояния при сбросе с ошибкой на единицу в настройке KTRR. Доступное для записи состояние пути сброса позволяло выполнять ROP после каждого сброса. Из-за ошибки на единицу __LAST.__pinst случайно вошла в исполняемую KTRR-область MMU, и инструкция MSR TTBR1_EL1, X0 осталась исполняемой.

ROP устанавливала новый корень таблицы страниц, отображавший __DATA_CONST на доступные для записи физические страницы. Исправить __TEXT_EXEC она не могла: KTRR в MMU уже работала и разрешала извлекать инструкции только из исходного физического диапазона, защищённого AMCC.

iOS 11.1.2: создайте собственный отладчик ядра iOS

async_wake_ios_with_kdp Иэна Бира создал одношаговый отладчик ядра для LLDB. Регистры самостоятельной отладки ARM, такие как DBGBCR<n>_EL1, DBGWCR<n>_EL1 и MDSCR_EL1, настраивают точки останова, точки наблюдения и отладочные исключения.

Отладчик нашёл системные вызовы и гаджеты, настраивавшие эти регистры. При срабатывании точки останова исправленный путь исключения зацикливался, сохранив прерванное состояние регистров в памяти. Другое ядро исследовало или изменяло это состояние. После вытеснения потока изменение сохранённого PC возобновляло выполнение в нужном месте.

Так удалось получить пошаговое выполнение и интеграцию с LLDB, но Apple удалила необходимые гаджеты. Кроме того, метод не позволял произвольно исправлять защищённый KTRR текст или поддерживать любые последующие выпуски iOS.

Исследование iBoot

iBoot проверяет и запускает kernelcache после SecureROM. Выполнение кода на этом этапе позволило бы загружать исправленное ядро, работать без актуальной уязвимости ядра и потенциально загружать более новые или старые выпуски после исправления самой ошибки iBoot.

Месяцы исследования iBoot не дали сразу нужной уязвимости, но снова и снова указывали на аппаратные средства отладки.

Все пути ведут к отладочным регистрам

Сошлись три подсказки:

• У регистров самостоятельной отладки ARM должен существовать и внешний интерфейс с отображением в память.

• Руководство ARMv8 отводит целую часть внешней отладке, отдельно от самостоятельной.

• Исследование Nailgun показало, что включённые отладочные регистры на оборудовании Android позволяют пересекать границы привилегий.

Сообщение паники сторожевого таймера iPhone содержало строку: Attempting to forcibly halt cpu 1. Поиск по XNU привёл к DebuggerXCallEnter() и ml_dbgwrap_halt_cpu(). Последняя использует индивидуальную для ядра базу coresight_base и volatile-указатель MMIO с именем dbgWrapReg.

Биты DBGWRAP останавливают, выключают и сбрасывают ядра. Что ещё удивительнее, ml_dbgwrap_halt_cpu_with_state() заставляет остановленное ядро выполнять сгенерированные инструкции, перемещающие регистры общего назначения через DBGDTR0. На динамически созданные инструкции не распространяются ограничения защищённых KTRR копий, поэтому остановленному ядру, вероятно, можно выдавать даже записи в критические системные регистры.

Копаем глубже

CoreSight — это внутрикристальная инфраструктура ARM для JTAG/SWD и другой внешней отладки. Событие отладки переводит ядро в состояние отладки вместо отправки на вектор исключения.

Регистр передачи инструкций (Instruction Transfer Register, ITR) заставляет остановленное ядро исполнить инструкцию. Регистры канала отладочной связи передают значения. Чтобы прочитать регистр общего назначения, XNU записывает в ITR инструкцию, перемещающую его значение в DBGDTR_EL0, а затем читает соответствующие MMIO-регистры DCC.

Поиск регистров

iBoot передаёт дерево устройств с описанием аппаратных диапазонов MMIO. Сравнение с cpu_regmap_paddr из XNU показало, что базой CoreSight ядра n служит cpus/cpu<n>/reg-private. На iPhone 8 действует следующий шаблон:

Регистры внешней отладки находятся по документированным смещениям относительно этой физической базы.

Проверка отладочных регистров

DBGAUTHSTATUS_EL1 по смещению 0xfb8 сообщает состояние отладочной аутентификации. Значение 0xf показало, что на серийном A11 включены и неинвазивная, и инвазивная отладка Non-Secure.

Я изменил voucher_swap так, чтобы он отображал страницы CoreSight и вызывал ml_dbgwrap_halt_cpu_with_state(). Значения регистров оказались корректными. Что ещё примечательнее, остановленное ядро выполняло физический адрес LowResetVectorBase с отключённой MMU.

Это означало, что в состояние отладки можно войти до инициализации KTRR.

Нужны дополнительные отладочные возможности

Остановки и внедрения инструкций было недостаточно. Сама внешняя отладка ARM не предлагала очевидного способа снова запустить ядро. A11 также отклонял инструкции загрузки и сохранения в состоянии отладки, хотя большинство операций MRS и MSR с системными регистрами работало.

Эксперименты с недокументированными битами DBGWRAP обнаружили три критически важных средства управления:

• Бит 29: войти в состояние отладки после следующего сброса, непосредственно перед выполнением вектора сброса.

• Бит 30: снова запустить ядро и продолжить обычное выполнение.

• Бит 26: по-видимому, предотвращать сброс, пока телефон подключён и активен.

Они предоставили недостающую возможность остановиться при сбросе, изменить состояние и продолжить работу.

Обход KTRR

Последовательность обхода выглядит так:

1. Выбрать вторичное ядро и установить бит 29 DBGWRAP.

2. Принудительно усыпить и разбудить это ядро, вызвав сброс с переходом в состояние отладки.

3. Использовать ITR/DCC для исследования регистров и пошагового выполнения инструкций вектора сброса.

4. Остановиться непосредственно перед инициализацией KTRR в MMU.

5. Изменить регистры общего назначения или PC так, чтобы пропустить путь настройки и блокировки KTRR.

6. Перезапустить ядро с помощью бита 30.

7. Установить таблицы страниц, отображающие исполняемую память ядра с правом записи на ядре, где KTRR в MMU так и не была заблокирована.

8. Исправить текст ядра и установить постоянный отладчик или загрузчик kext.

KTRR в AMCC по-прежнему отклоняет физические записи в исходную защищённую область. Отладчик повторно отображает защищённые виртуальные страницы на доступные для записи копии за пределами физического диапазона, исправляет копии и выполняет их на ядре без ограничений KTRR в MMU.

KTRW

KTRW оформляет обход как загрузчик kext и отладчик ядра для iOS. Он может скомпилировать программу на C в Mach-O, динамически загрузить её и скомпоновать с работающим ядром. Заглушка GDB взаимодействует по USB и интегрируется с LLDB и IDA Pro.

Для его создания потребовался не только обход, но и стек USB для недокументированного оборудования. Реализация опубликована с комментариями, объясняющими эти компоненты.

Техника работает на A11. На A12 внешняя отладка, по-видимому, недоступна, а на A9 и A10 лишь частично работает по неожиданным базовым адресам. Возможно, дополнительные возможности включает проприетарная инициализация, но подтвердить это не удалось.

Является ли это уязвимостью безопасности?

Для использования этих регистров необходимо произвольное чтение и запись ядра, чтобы отобразить MMIO и управлять ядрами. На этом этапе устройство уже полностью скомпрометировано, а данные приложений доступны. KTRW главным образом расширяет возможности атакующего или исследователя изменять и отлаживать ядро, а не преодолевает первую границу безопасности.

Анализ эксплойтов, применявшихся в реальных атаках показывает, что одного чтения и записи ядра было достаточно для запуска пользовательского импланта, похищавшего конфиденциальные данные через обычные API.

Исследовательские телефоны и эксплойты SecureROM

Apple анонсировала инженерные устройства для исследователей на Black Hat 2019. Неограниченный доступ к такому оборудованию улучшил бы открытые исследования. Общедоступный эксплойт SecureROM также решает большинство задач исследовательской платформы без уязвимости ядра и, вероятно, станет основой будущих исследовательских сред для A11.

Внешняя отладка сохраняет ценность, поскольку после получения чтения и записи ядра может обойти KTRR и отлаживать ядро даже без уязвимости SecureROM.

Заключение

Путь оказался удивительно прямым: предыдущие открытые работы по самостоятельной отладке, обширная документация ARM по внешней отладке, Nailgun и исходный код XNU вместе описывали почти все необходимые компоненты.

Это вызывает опасение, что частные возможности исследования iOS существенно разошлись с общедоступным уровнем техники. По-видимому, сведения об этих отладочных регистрах циркулировали в закрытых кругах, и, вероятно, существуют другие способы обхода KTRR, включая техники для A12.

Публикация KTRW даёт исследователям на обычных розничных устройствах возможности, более близкие к доступным на инженерном оборудовании. У атакующих уже есть сложные инструменты; сокращение разрыва между закрытыми наступательными знаниями и открытыми защитными исследованиями помогает повысить безопасность iOS.

Ошибка была раскрыта с семидневным сроком, поскольку достоверные свидетельства указывали на существование эксплойта и его вероятное применение против пользователей.

Работа Project Zero с уязвимостями нулевого дня из реальных атак сосредоточена на двух направлениях:

• Выполнять анализ вариантов, чтобы после исправления одного экземпляра атакующие не могли дёшево перейти к родственной ошибке.

• Публиковать анализ первопричины и эксплуатации, чтобы производители, защитники, аналитики угроз и специалисты по реагированию могли улучшить предотвращение и обнаружение.

Поиск ошибки

В конце лета 2019 года Threat Analysis Group Google, Android Security и Project Zero получили сведения, указывавшие, что NSO располагала уязвимостью нулевого дня Android в цепочке установки Pegasus. Доступные описания возможностей содержали необычно конкретные подсказки:

• Ошибка находилась в ядре.

• Она была доступна из домена SELinux isolated_app Chrome.

• Она затрагивала Pixel 1 и Pixel 2, но не Pixel 3.

• Эксплуатация не работала при включённом CONFIG_DEBUG_LIST.

• Эксплойт изменял предел адресов текущего процесса в task_struct.

Только вставка и удаление элементов связного списка существенно меняются при CONFIG_DEBUG_LIST, поэтому освобождённый объект, вероятно, содержал узел списка, который позднее добавлялся или удалялся. Подсказка о пределе адресов указывала на примитив перезаписи task_struct.addr_limit.

Сравнение драйверов Binder Pixel 2 и Pixel 3 и журналов изменений выявило коммит 550c01d0e051461437d6e9d72f573759e7bc5047. Он соответствовал всем подсказкам. Около 25 других изменений Binder не соответствовали.

Первоначальное обнаружение

Syzbot впервые сообщил об использовании после освобождения в списки рассылки Linux и syzkaller в ноябре 2017 года. Исправления попали в Linux 4.14 и Android 3.18, 4.4 и 4.9 в феврале 2018 года.

В отчёте и патче влияние на безопасность не было обозначено чётко. Исправление так и не появилось в ежемесячном бюллетене безопасности Android, поэтому уже выпущенные устройства, включая Pixel и Pixel 2, остались уязвимыми.

Android узнала о последствиях для безопасности от Project Zero 26 сентября 2019 года, назначила CVE-2019-2215 и за 24 часа уведомила партнёров, предоставив исправление.

Технические подробности

binder_thread включает wait_queue_head_t wait. Вызов poll() для файла Binder заставляет binder_poll() зарегистрировать эту очередь ожидания в epoll. Затем BINDER_THREAD_EXIT вызывает binder_thread_release() и освобождает содержащий объект, пока epoll всё ещё хранит указатель на wait.

Обычно очереди ожидания poll файла действительны до освобождения файла. Для редкого раннего уничтожения требуется POLLFREE; Binder его не использовал и фактически требовал от вызывающих сторон удалять и повторно добавлять наблюдение epoll ради безопасности.

Последующий EPOLL_CTL_DEL вызывает remove_wait_queue() для освобождённой памяти:

Само обращение к спин-блокировке является использованием после освобождения, но полезный примитив записи предоставляет list_del(). Без отладочных проверок списка она выполняет:

При CONFIG_DEBUG_LIST функция __list_del_entry() проверяет prev->next == entry и next->prev == entry; неудачная проверка запускает BUG_ON. Android обычно вызывает панику при oops, предотвращая эту стратегию эксплуатации.

Эксплуатация использования после освобождения

Доказательство концепции Project Zero запускает использование после освобождения дважды:

1. Повторно выделяет binder_thread как массив iovec и раскрывает указатель текущей task_struct.

2. Повторяет операцию и перезаписывает task_struct.addr_limit.

Повышение addr_limit заставляет адреса ядра проходить проверки usercopy, предоставляя непривилегированному процессу произвольное чтение и запись ядра.

О векторном вводе-выводе

Ввод-вывод со сбором и разбрасыванием описывает несколько буферов структурой struct iovec:

writev() собирает байты из нескольких буферов в файл. readv() и recvmsg() распределяют байты по нескольким буферам назначения.

Ядро импортирует вектор пользовательского пространства через rw_copy_check_uvector(), проверяет каждый исходный указатель и сохраняет копию в ядре. После начала блокирующей операции указатели повторно не проверяются. Если использование после освобождения изменяет импортированный iov_base, пока ввод-вывод заблокирован, последующая операция обращается к новому адресу ядра.

iovec имеет размер 16 байт, а binder_thread — 408 байт. Массив из 25 векторов занимает 400 байт и повторно использует тот же блок, не перезаписывая указатель task_struct в конце объекта.

Использование векторного ввода-вывода для чтения и записи UAF

Импортированный вектор перекрывает освобождённую очередь ожидания Binder. Указатели списка по смещениям 0xa8 и 0xb0 перекрывают поля выбранных векторов. list_del() переписывает их адресом головы списка, превращая один iov_base в указатель ядра.

Полная последовательность:

Утечка task_struct

Эксплойт подготавливает 25 векторов. Первые десять пропускаются. iovec[10] указывает на фиктивную страницу, выровненную по 4 ГиБ, чтобы младшие биты адреса напоминали разблокированную спин-блокировку. Её длина равна ёмкости канала.

Изначально канал заполнен. writev() импортирует вектор, обрабатывает фиктивные данные и блокируется до использования iovec[11]. Другой поток выполняет EPOLL_CTL_DEL; list_del() изменяет iovec[11].iov_base на голову списка очереди ожидания ядра по адресу binder_thread + 0xa8.

Опустошение канала продолжает writev(), которая собирает байты с этого адреса ядра. Чтение канала возвращает содержимое перекрытого объекта. По смещению 0xe8 от утёкшей области головы списка находится указатель, хранящийся по адресу binder_thread + 0x190: текущая task_struct.

Перезапись предела адресов

Эксплойт запускает новое использование после освобождения с recvmsg() для распределённой записи. То же удаление из списка меняет iovec[11].iov_base на адрес головы списка.

iovec[11].iov_len равен 0x28, поэтому входящие байты сокета перезаписывают ровно пять qword:

• iovec[10].iov_len

• iovec[11].iov_base

• iovec[11].iov_len

• iovec[12].iov_base

• iovec[12].iov_len

Полезная нагрузка устанавливает iovec[12].iov_base в task_struct + 0x8 — адрес сохранённого addr_limit. Когда распределённая обработка переходит к вектору 12, она записывает туда 0xfffffffffffffffe. Это на единицу меньше KERNEL_DS, что позволяет избежать ветви segment_eq(get_fs(), KERNEL_DS) в iov_iter_init(), но разрешает практически все адреса ядра.

Обычные операции канала и usercopy теперь предоставляют произвольное чтение и запись ядра.

Анализ реальной эксплуатации

Project Zero не располагала бинарным файлом эксплойта. Свидетельства состояли из маркетинговых документов и описаний возможностей, подробных подсказок о методологии, контекста Pegasus и анализа патчей, показавшего, что всем условиям соответствует ровно одна известная ошибка.

Этого было достаточно для семидневного срока. Требование захваченного образца в каждом случае оставляло бы пользователей незащищёнными, когда достоверные контекстные свидетельства уже показывают активную эксплуатацию.

Анализ вариантов

Самый важный класс вариантов имеет скорее эксплуатационный, чем чисто синтаксический характер: исправления вышестоящих Linux и Android могут влиять на безопасность, не будучи помечены как ошибки безопасности. Такие патчи могут никогда не попасть в бюллетени безопасности Android и поэтому отсутствовать на выпущенных устройствах.

Ручная проверка каждого патча Linux не масштабируется. Регулярная синхронизация ядер устройств со стабильными вышестоящими ядрами и общими ядрами Android закрыла бы многие такие разрывы. Project Zero также искала другие обработчики poll, очереди ожидания которых переживали содержащие их файлы, но не обнаружила столь же значимой проблемы.

Заключение

CVE-2019-2215 позволяла полностью скомпрометировать устройство из недоверенного приложения или процесса отрисовки браузера. Хотя вышестоящий проект исправил её в начале 2018 года, выпущенные устройства Android оставались уязвимыми почти два года.

Ошибки ядра представляют особенно широкую поверхность атаки Android, поскольку код фреймворков производителей, системы на кристалле и предустановленные приложения различаются, тогда как многие устройства имеют общее происхождение ядра. Одна уязвимость Binder затронула значительную часть экосистемы до сентября 2018 года.

Project Zero раскрыла проблему через семь дней после сообщения. Android обновила бюллетень за октябрь 2019 года 6 октября; устройства с уровнем исправлений безопасности на эту дату или позже должны содержать исправление.

Чтобы усложнить эксплуатацию нулевого дня, необходимо изучать ошибки из реальных атак, устранять их варианты, сокращать разрывы в исправлениях и делиться подробностями эксплуатации с широким сообществом защитников.

В этой публикации пошагово рассматривается разработка SockPuppet — эксплойта CVE-2019-8605 для iOS 12.4. Вместо демонстрации только окончательной цепочки здесь объясняется, как сетевой фаззинг обнаружил ошибку, как небольшой воспроизводящий пример превратился в стабильный примитив использования после освобождения и как на основе этого примитива был создан поддельный порт задачи ядра (tfp0).

Процесс следует принципам из статьи «Какой должна быть хорошая уязвимость повреждения памяти?»: точно понять, что освобождается, сохранить полезную висячую ссылку, предсказуемо занять выделение заново и использовать каждый промежуточный примитив, чтобы сделать следующий этап надёжнее.

Поиск ошибок Почему сетевой фаззинг?

Сетевой стек XNU — большая, старая и зависящая от состояния поверхность атаки, доступная процессам в песочнице. Операции с сокетами предоставляют множество сочетаний доменов, типов, протоколов, параметров, состояний подключения и последовательностей завершения. При этом тот же интерфейс доступен через компактный набор системных вызовов, поэтому удобно генерировать последовательности, а не изолированные входные данные.

Фаззер представлял операции с помощью Protocol Buffers. Например, команда создания сокета выбирала домен, тип и протокол из перечислений:

Сгенерированный тестовый пример оставался понятным человеку:

Среда выполнения отслеживала живые файловые дескрипторы и выбирала только действительно созданные. Команды socket, bind, connect, setsockopt, getsockopt, shutdown и close объединялись в программы с состоянием. Так большая часть запусков не тратилась на заведомо недопустимые дескрипторы, но необычные переходы состояния оставались возможными.

От Protobuf к PoC

Одна минимизированная последовательность создавала два сокета IPv6, задавала параметр IPv6, отключала один сокет, а затем обращалась к параметру после освобождения его базовой структуры. ASAN показал двойное освобождение в in6_pcbdetach() через путь завершения raw IPv6:

Уязвимый код очистки освобождает параметры протокола, но оставляет путь, по которому операции с параметрами сокета продолжают использовать устаревший указатель in6p_outputopts:

Ранний обходной путь в среде выполнения подавлял обращения после перехода inp_state в мёртвое состояние, скрывая простое чтение после освобождения:

Удаление этого предположения открыло более полезный примитив. Генерируемые имена параметров также заменили с произвольных целых чисел на типизированное перечисление, чтобы фаззер эффективнее исследовал допустимые пути.

Ключевой параметр сокета — SO_NP_EXTENSIONS. Его флаг SONPX_SETOPTSHUT разрешает вызывать setsockopt после завершения работы:

Минимизированный пример создаёт TCP-сокет IPv6, разрешает параметры после завершения, выделяет параметры пакетов IPv6, отключает сокет, чтобы эти параметры освободились, а затем вызывает getsockopt или setsockopt через висячий указатель. Это и есть CVE-2019-8605.

Эксплуатация Как работает использование после освобождения

Висячим объектом является структура ip6_pktopts, на которую ссылается inpcb.inp6_outputopts.

Несколько функций получения параметров напрямую возвращают поля этой структуры. Целые числа minmtu и prefer_tempaddr дают небольшие операции чтения по известным смещениям. IPV6_PKTINFO мощнее: если ip6po_pktinfo не равен null, ядро копирует 20 байт по указателю, хранящемуся в повторно занятом объекте.

Если освобождённое выделение повторно занять контролируемыми байтами, эти поля дают воспроизводимый примитив чтения. Поэтому эксплойт должен распылить данные в той же зоне аллокатора и определить, какое распылённое выделение заместило жертву.

Начальная загрузка более мощных примитивов

IOSurface используется для распыления в памяти ядра контролируемых данных свойств переменного размера. Создаётся множество выделений с различными значениями-маркерами. После освобождения чтение параметров сокета раскрывает маркер объекта распыления, занявшего слот ip6_pktopts. Теперь эксплойт знает и то, что замещение удалось, и то, какое свойство нужно изменить.

Первое полезное расположение помещает выбранный указатель ядра по смещению ip6po_pktinfo. getsockopt(IPV6_PKTINFO) следует по нему и копирует наружу 20 байт, предоставляя произвольное чтение ядра небольшого фиксированного размера. Повторные вызовы позволяют читать более крупные диапазоны.

Реализация и проверка распыления кучи

Надёжность зависит от поведения аллокатора, а не только от времени. Эксплойт:

1. выделяет множество свойств IOSurface целевого размера;

2. создаёт пустоты, удаляя контролируемое подмножество;

3. выделяет уязвимый параметр сокета в одной из этих пустот;

4. освобождает параметр, сохраняя висячий указатель сокета;

5. повторно заполняет пустоты помеченными данными IOSurface;

6. читает через висячий указатель, чтобы определить победившее выделение.

Можно подготовить несколько сокетов, чтобы неудачное замещение не завершало попытку. Маркеры отличают устаревшие данные, другой объект ядра и успешно занявшее память распылённое выделение. Это превращает вероятностное событие кучи в проверяемый переход состояния.

Знакомство с tfp0

Традиционная цель джейлбрейка iOS — право на отправку порту, представляющему kernel_task. Mach-сообщения несут заголовок с именами портов назначения и ответа, битами и размером сообщения:

mach_msg_overwrite_trap() копирует сообщение пользовательского пространства в ipc_kmsg; ipc_kmsg_copyin_header() разрешает имена портов в IPC-пространстве отправителя; ipc_right_copyin() проверяет права и преобразует имена в указатели ipc_port; наконец, ipc_kmsg_send() ставит сообщение в очередь порта назначения.

Элемент таблицы IPC-пространства хранит объект ядра и права задачи:

Цель — добавить в собственную таблицу IPC элемент, у которого ie_object является поддельным портом, связанным с kernel_task, а ie_bits предоставляют право на отправку.

Поддельный порт должен пройти проверки, выполняемые при преобразовании порта задачи. task_conversion_eval() разрешает задаче разрешать собственный порт задачи, а kernel_task — любой порт задачи. Поэтому поддельный порт с правильным пространством получателя и отношением задачи способен пройти путь преобразования, используемый mach_vm_read, mach_vm_write и родственными API.

Обход ASLR и подделка структур данных

Многие цепочки эксплойтов сначала повреждают память и лишь потом получают примитив чтения. Необычное преимущество SockPuppet — надёжное чтение до разрушительного повреждения. Отдельная утечка указателя предоставляет начальный адрес, а произвольное чтение обходит структуры ядра и находит всё необходимое для окончательных поддельных объектов.

Массив дескрипторов внестрочных портов распыляется указателями на порт хоста. Чтение одного распылённого дескриптора раскрывает его ipc_port; получатель порта раскрывает ipc_space_kernel. Из структур текущей задачи и процесса эксплойт получает собственную таблицу IPC. Он также находит kernel_task, её карту и необходимые адреса ядра для создания поддельных задачи и порта.

Контролируемые данные IOSurface хранят поддельные структуры по известному утёкшему адресу. Поля заполняются консервативно: тип объекта и счётчики ссылок допустимы, указатели получателя и kobject ведут к ожидаемым объектам, а поддельная задача указывает на карту ядра. Эксплойт не изменяет посторонние поля, чтобы последующий код Mach следовал обычными путями.

Внедрение нашего порта kernel_task

Остаётся записать указатель в таблицу IPC текущей задачи. Массивы внестрочных портов предоставляют выделения ядра с повторяющимися указателями ipc_port. Если таким массивом повторно занять память висячего ip6_pktopts, функции установки параметров сокета могут изменять выбранные байты существующего указателя. В сочетании с формированием кучи и знанием структуры таблицы это даёт ограниченную запись, необходимую для перенаправления элемента IPC на поддельный порт.

Биты прав элемента подготавливаются как допустимое право на отправку. Когда слот таблицы начинает именовать поддельный порт, пользовательское пространство вызывает операцию порта задачи. Mach разрешает имя через изменённый элемент, следует по поддельному порту к поддельной задаче и получает доступ к настоящей карте ядра. После этого стандартные операции mach_vm_* предоставляют стабильное чтение и запись ядра: tfp0 получен.

После успеха эксплойт тщательно управляет ссылками и распылёнными объектами. Структуры ядра, остающиеся достижимыми, не освобождаются преждевременно, а временные порты уничтожаются только тогда, когда учёт их ссылок безопасен.

Оценка PAC и MTE

Техника разрабатывалась на устройствах без Pointer Authentication, но важными повреждаемыми значениями служат указатели на данные, а не адреса возврата или подписанные указатели на функции. PAC на A12 не предотвращает автоматически UAF, примитив чтения или манипуляции с таблицей IPC. Более широкое подписание ценных данных ядра могло бы повысить стоимость атаки, как обсуждается в статье «Исследование Pointer Authentication на iPhone XS».

Memory Tagging Extension может обнаружить повторное использование освобождённого выделения, если висячий указатель и замещающий объект получат разные теги. Эффективность зависит от генерации тегов, интеграции с аллокатором и возможности атакующего повторять попытки или определять теги. Ни одну меру защиты не следует оценивать лишь по одному эксплойту; важнее понять, разрушает ли она примитивы, доступные в реалистичных цепочках.

Мета iOS-эксплойтов

SockPuppet следует узнаваемой схеме современных эксплойтов iOS: получить начальный примитив нарушения безопасности памяти, построить чтение ядра, раскрыть адреса, распылить поддельные Mach-объекты, получить ограниченную запись и превратить поддельный порт в tfp0. Эта экосистема известных техник делает разработку эксплойтов модульной, но также означает, что защитные изменения центральных структур вроде ipc_port, преобразования задач и порта задачи ядра способны нарушить сразу многие цепочки.

Полезное сравнение даёт цепочка эксплойтов для iOS, применявшаяся в реальных атаках. Подробности её эксплуатации, особенно создание поддельных объектов, подробнее рассмотрены во второй части.

Жизнь ошибки

CVE-2019-8605 появилась, когда поведение параметров сокета после завершения работы добавили без полного согласования с уничтожением блока управления протоколом. Об ошибке сообщили Apple, её исправили, а затем она получила широкую известность, поскольку iOS 12.4 случайно вернула уязвимость после исправления в 12.3.

Корневая причина не сводится к отсутствующему присваиванию null. Две подсистемы расходятся в понимании времени жизни объекта: отключение уничтожает параметры IPv6, а SO_NP_EXTENSIONS разрешает более поздние операции, предполагающие, что эти параметры ещё действительны. Надёжное исправление должно сделать переход состояния явным и обеспечить, чтобы все пути параметров последовательно отклоняли отключённый PCB или безопасно обрабатывали его.

Сводка примитивов Заключение

SockPuppet демонстрирует весь путь от сбоя фаззера до стабильного эксплойта ядра. Сетевой фаззинг с состоянием обнаружил расхождение во времени жизни, которое мог пропустить фаззер системных вызовов без состояния. Тщательный анализ превратил висячие параметры сокета в примитив чтения; учитывающие аллокатор распыления сделали повторное занятие наблюдаемым; знание Mach IPC преобразовало ограниченное повреждение в поддельный порт задачи ядра.

Самый универсальный урок — формулировать явные промежуточные цели. Каждый этап должен раскрывать достаточно состояния, чтобы проверить успех и подготовить следующий. Надёжный эксплойт — это не одно изобретательное повреждение, а последовательность небольших измеримых примитивов с понятными предположениями.

В Project Zero мы уделяем много времени обсуждению и оценке политик раскрытия уязвимостей и их последствий для пользователей, разработчиков, коллег-исследователей и общих норм безопасности программного обеспечения в отрасли. Мы очень довольны результатами своей политики за последние пять лет. Скорость исправления серьёзных уязвимостей заметно выросла, и теперь 97,7% наших отчётов устраняются в пределах установленного 90-дневного срока.

При этом тема остаётся сложной и часто вызывает споры как внутри команды, так и за её пределами. Мы регулярно получаем от тесно сотрудничающих с Project Zero разработчиков отзывы о действующей политике: иногда они предлагают изменения, а иногда рассказывают о положительном влиянии нашей работы на них и их пользователей. Такие обсуждения помогали развивать политику на протяжении многих лет. Например, в 2015 году после полезных бесед с разными разработчиками мы ввели 14-дневный льготный период.

Недавно мы пересмотрели политику и цели, которых надеемся достичь раскрытием. По итогам обзора было решено изменить политику раскрытия уязвимостей в 2020 году. Сначала опишем изменения, а затем объясним их причины.

Краткое описание изменений 2020 года

Для уязвимостей, зарегистрированных начиная с 1 января 2020 года, политика меняется: по умолчанию предоставляются полные 90 дней независимо от момента исправления ошибки.

Исправили ошибку за 20 дней? Все сведения будут опубликованы на 90-й день.

Исправили ошибку за 90 дней? Все сведения будут опубликованы на 90-й день.

По взаимному согласию разработчика и Project Zero отчёт можно открыть раньше истечения 90 дней. Например, разработчик может захотеть синхронизировать публикацию нашего отчёта в трекере со своими примечаниями к выпуску, чтобы сократить путаницу и число вопросов пользователей.

Мы будем испытывать политику 12 месяцев, а затем решим, следует ли сохранить её надолго.

Полный список изменений 2020 года:

• Льготный период — дополнительные 14 дней, которые разработчик может запросить, если не рассчитывает исправить зарегистрированную уязвимость в течение 90 дней, но ожидает сделать это в пределах 104 дней. Если льготный период запрошен и ошибка исправлена между 90-м и 104-м днём после регистрации, сведения публикуются в день исправления. Льготный период не предоставляется для уязвимостей, устранение которых, как ожидается, займёт более 104 дней. Обратите внимание, что семидневный срок для активно эксплуатируемых в реальных атаках уязвимостей остаётся неизменным.

Мы постоянно оцениваем, служит ли политика безопасности пользователей, и считаем изменение ещё одним шагом в правильном направлении. Кроме того, новая политика проста, последовательна и справедлива.

Обоснование изменений 2020 года

Последние пять лет команда использовала политику раскрытия уязвимостей для достижения одной основной цели: ускорения разработки патчей.

Мы хотим повысить стоимость атак с применением эксплойтов нулевого дня. Для этого мы используем опыт наступательного исследования уязвимостей и свидетельства поведения настоящих злоумышленников. Работа включает обнаружение и регистрацию большого числа уязвимостей безопасности. Этот опыт показал, что скорость разработки и развёртывания патчей чрезвычайно важна и нуждается в улучшении во всей отрасли.

Если разработка и развёртывание занимают много времени, мы быстро начинаем отставать: новых ошибок появляется больше, чем разработчики успевают исправить, и возвращение в нормальное состояние требует титанических усилий.

Кроме того, наши исследования регулярно сталкиваются с «совпадением ошибок»: обнаруженная нами уязвимость уже была найдена и использовалась настоящим атакующим. Осознание того, что найденные проблемы часто уже тайно применяются во вред пользователям, создаёт чувство срочности, поэтому мы просим разработчиков исправлять их как можно быстрее.

После пяти лет применения 90-дневного срока мы гордимся результатами: уязвимости исправляются быстрее, чем когда-либо. Около момента запуска Project Zero в 2014 году на устранение некоторых проблем уходило более шести месяцев. К 2019 году 97,7% наших ошибок исправлялись в срок. Тем не менее возможности для улучшения сохраняются как в скорости отраслевой разработки патчей, так и во всём жизненном цикле управления уязвимостями.

Пересмотр основных принципов и целей политики

Недавно мы сформулировали лежащие в основе политики принципы:

• Простота. Политику должно быть легко понять. Кроме того, мы хотим работать в большом масштабе, иначе настойчиво побуждать всю отрасль к улучшению станет ещё труднее.

• Последовательность. Мы хотим быть надёжными и предсказуемыми. Сроки должны применяться детерминированно, без страха и предпочтений, показывая серьёзность наших слов. Планка любого исключения или отступления должна оставаться чрезвычайно высокой. За пять лет существования команды было всего два исключения.

• Справедливость. Мы стремимся к равноправию, балансу и беспристрастности. Разные разработчики, включая Google, не должны получать привилегий. Ко всем применяются одинаковые правила.

В ходе обсуждений стало понятно, что необходимо добавить ещё две цели. Итак, цели политики 2020 года:

1. Более быстрая разработка патчей (существующая): разработчики должны быстро создавать исправления и иметь процессы их доставки конечным пользователям. Мы продолжим настойчиво добиваться этого.

2. Тщательная разработка патчей (новая): слишком часто разработчики исправляют зарегистрированную уязвимость, лишь «замазывая трещины», не рассматривая варианты и не устраняя первопричину. Есть опасение, что цель ускорения патчей усугубляет проблему и позволяет атакующим с минимальными усилиями оживлять эксплойты и продолжать нападения.

3. Более широкая установка патчей (новая): обнаружение и даже исправление ошибки само по себе не повышает безопасность конечного пользователя. Она улучшается, когда пользователь узнаёт о проблеме и обычно обновляет устройство. Поэтому своевременная установка важна, чтобы пользователи действительно получили пользу от исправления.

Новое направление политики 2020 года создаёт ясные стимулы для разработчиков, особенно тех, кто ранее поднимал следующие вопросы.

• С момента основания Project Zero некоторые разработчики считают вредной публикацию сведений до широкого распространения патча. Мы не согласны, поскольку, как объясняет наш FAQ, эта информация уже известна и используется атакующими. Но новая политика должна стимулировать таких разработчиков исправлять быстрее, поскольку ранний патч оставит им «дополнительное время» на распространение.

• Полное 90-дневное окно доступно для анализа первопричин и вариантов. Мы ожидаем более итеративных и тщательных исправлений, устраняющих возможность слегка изменить эксплойт и оживить его.

• Мы явно ставим цель повысить установку патчей, стимулируя разработчиков предлагать обновления и убеждать большую часть пользователей установить их в пределах 90 дней.

Нам также нравится, что политика повышает последовательность процесса раскрытия, оставаясь простой и справедливой. Например, некоторые разработчики считали наше определение момента исправления непредсказуемым, особенно при одновременной работе с несколькими исследователями команды. Это мешало сотрудничать с нами по крупным проблемам, поэтому мы устраним препятствие и посмотрим, улучшится ли ситуация. Надеемся, эксперимент побудит разработчиков быть с нами открытее, делиться данными, укреплять доверие и улучшать сотрудничество.

Политика раскрытия — сложная тема с множеством компромиссов. Мы не ожидаем, что она понравится всем, но с оптимизмом считаем её улучшением действующего подхода, хорошим балансом стимулов и положительным шагом для безопасности пользователей. В конце 2020 года мы планируем оценить, достигает ли она поставленных целей.

Это первая статья серии из трёх частей о том, как уязвимость iMessage можно было удалённо эксплуатировать без взаимодействия с пользователем в iOS 12.4. Она развивает материал презентации автора на 36C3. В этой части исследуется уязвимость; во второй части создаётся удалённый обход ASLR, а в третьей он превращается в удалённое выполнение кода.

Зная только Apple ID, номер телефона или адрес электронной почты жертвы, продемонстрированная атака могла за несколько минут захватить управление устройством iOS. Она не требовала взаимодействия и не показывала уведомлений. После компрометации атакующий мог получить доступ к файлам, паролям, кодам двухфакторной аутентификации, сообщениям, электронной почте и данным приложений либо включить микрофон и камеру. Одна уязвимость, CVE-2019-8641, сначала использовалась для обхода ASLR, а затем для выполнения кода за пределами песочницы.

Уязвимость была обнаружена в ходе совместного исследования с Натали Сильванович и зарегистрирована в Apple 29 июля 2019 года; 9 августа последовало доказательство концепции. В iOS 12.4.1 уязвимый код стал недоступен через iMessage, а iOS 13.2 полностью исправила ошибку. Опубликованное доказательство концепции для iPhone XS намеренно показывает уведомления и останавливается до выполнения нативного шелл-кода, чтобы затруднить несерьёзные злоупотребления.

Опытные атакующие уже могли получить похожие возможности, находя ошибки, исследуя патчи методами из статьи «Эксплойты JSC» или сочетая утечку информации CVE-2019-8646 с другой ошибкой повреждения памяти.

Архитектура iMessage

Входящие сообщения iMessage проходят через несколько служб и фреймворков, прежде чем появится уведомление и сообщение попадёт в базу данных. На схеме красная рамка обозначает изолированный процесс.

Удалённо доступная поверхность, сложный API NSKeyedUnarchiver и формат iMessage рассмотрены в статье «Полностью удалённая поверхность атаки iPhone». Ошибку NSKeyedUnarchiver обычно можно было запустить либо в изолированном imagent, либо в неизолированном SpringBoard. SpringBoard изначально работает вне песочницы, но его сбой вызывает заметный перезапуск интерфейса. imagent может аварийно завершаться и перезапускаться без наблюдаемого поведения системы.

В iOS 13 декодирование NSKeyedUnarchiver, по-видимому, перенесли из SpringBoard в изолированный IMDPersistenceAgent, существенно сократив неизолированную поверхность атаки iMessage.

Доставка iMessage

Для доставки эксплойта нужны нестандартные сообщения, взаимодействие с серверами Apple и сквозное шифрование iMessage. В исследовании повторно использовалась реализация Apple путём перехвата imagent с помощью Frida:

1. Создать полезную нагрузку и сохранить её на диске.

2. Попросить Messages.app отправить цели сообщение-заполнитель, например REPLACEME.

3. Перехватить imagent и заменить исходящий заполнитель полезной нагрузкой до передачи.

Та же техника позволяет перехватывать функции получателя для исследования входящих сообщений. Обычное сообщение-заполнитель в виде бинарного plist выглядит так:

Перехватчик Frida добавляет сериализованный атакующий объект до шифрования и отправки сообщения:

imagent получателя декодирует ati через NSKeyedUnarchiver. Репозиторий инструментов обмена сообщениями iOS содержит примеры перехватчиков отправки и получения.

CVE-2019-8641

CVE-2019-8641 возникает при распаковке NSSharedKeyDictionary — специализированного NSDictionary, ключи которого заранее объявляются в NSSharedKeySet. Набор ключей может указывать на subSharedKeySet, образуя связный список.

NSKeyedArchiver сохраняет граф объектов в виде plist. Объекты занимают индексированный массив, а значения CFKeyedArchiverUID ссылаются на них. При декодировании NSKeyedUnarchiver добавляет объект в свою карту UID до вызова initWithCoder. Это позволяет создавать циклические графы, но также открывает доступ к объектам, инициализация которых ещё не завершена.

Соответствующие конструкторы можно свести к следующему псевдокоду:

indexForKey: ищет в текущем наборе, а затем рекурсивно проходит по цепочке вложенных наборов:

Вредоносный архив создаёт два набора ключей с циклом: SharedKeySet1 указывает на SharedKeySet2, а второй — обратно на первый.

Во время декодирования SharedKeySet1 имеет управляемые атакующим _numKey и _rankTable, но _keys всё ещё равен null. SharedKeySet2 завершает декодирование, и проверка его ключей вызывает indexForKey:. Первый ключ разрешается локально; поиск второго проходит по циклической ссылке в лишь частично инициализированный SharedKeySet1. После этого управляемые атакующим таблица рангов и количество задают индекс относительно нулевого указателя _keys.

Полученное значение интерпретируется как указатель на объект Objective-C (id). Примитив может разыменовать почти произвольный адрес с двумя ограничениями:

• Адрес должен делиться на 8, поскольку _keys содержит элементы размером с указатель.

• Он должен находиться ниже 32 ГБ, поскольку индекс является беззнаковым 32-разрядным целым числом.

В iOS интересующая память процесса обычно находится ниже 0x800000000, поэтому это на первый взгляд обычное разыменование нулевого указателя становится полезным примитивом эксплуатации. На данном этапе атакующий всё ещё ничего не знает об адресном пространстве цели; построению утечки информации посвящена вторая часть.

Сначала пакеты macOS казались интересными только из-за актуальных символов JP2K и 3D. Более тщательное исследование обнаружило значительно больше общедоступных отладочных метаданных, включая сведения, отсутствующие в других источниках символов и более новые, чем последние сборки Unix. Устаревшие установщики по-прежнему доступны на серверах исторических загрузок Adobe.

Обзор основных образов Mach-O Acrobat

Шесть основных компонентов Reader имеют следующее покрытие символами. «Частные» означает полные частные метаданные, включая локальные переменные, структуры, пути исходников и соответствие строкам.

1. Доступность зависит от младшего выпуска 8.x.

2. Доступность зависит от младшего выпуска 9.x.

3. Символы AGM присутствуют до 15.016.20045 включительно и удалены в последующих версиях.

Adobe Reader 8.x Adobe Reader 9.x

Частные метаданные stabs встречаются в модуле 3D версии 7.x и большинстве сборок CoolType 9.x. Они включают имена функций и глобальных объектов, пути и строки исходников, локальные переменные, структуры и перечисления. По-видимому, эти частные символы больше нигде не доступны публично.

Символы Acrobat, AGM, CoolType и BIB версий 8.x и 9.x также новее своих Unix-аналогов. Reader 9 в macOS значительно проще запускать для анализа сбоев, чем Reader 9 в Solaris или Reader 7 в AIX либо HP-UX. AGM оставался без удалённых символов в Reader DC с версии 15.006.30033 в марте 2015 года до 15.016.20045 в июне 2016 года.

CoolType — самая полезная находка, поскольку родственный код растеризации также присутствует в win32k.sys, atmfd.dll и dwrite.dll в Windows, libTrueTypeScaler.dylib и libType1Scaler.dylib в macOS, а также libt2k.so в Java.

Подробное исследование символов CoolType

Семнадцать уникальных образов AdobeCoolType из Reader 9.x содержат текстовые данные stabs. Некоторые строки определяют процедуры открытого проекта AFDKO, например t1cParse, t1cDecrypt и t1cUnprotect. Более ценные записи раскрывают полную структуру стека Type1InterpretCharString, включая имена аргументов и локальных переменных.

Образ AdobeCoolType размером 6,35 МБ из Reader 9.5.5 содержит около 1,78 МБ отладочных строк. IDA Pro и Ghidra распознают имена функций и глобальных объектов, но, по-видимому, не импортируют типы и локальные переменные stabs. Старые objdump и особенно gdb от Apple это делают.

В установленном Reader 9.5.5 на Mac OS X 10.6.8 gdb загружает встроенные символы, предупреждая, что исходные объектные файлы и исходники Adobe отсутствуют:

Среди полезных команд — info functions, info line, info sources, info types и info variables. Например, символы раскрывают точный прототип и файл исходного кода интерпретатора Type 1:

Доступны и типы:

Анализ задачи № 1888 (CVE-2019-8048)

Символы становятся особенно ценными при интерактивном анализе сбоев. Запуск задачи 1888 в Reader 9.5.5 напрямую определяет место ошибки и строку исходного кода:

По сравнению с обычной трассировкой без символов здесь определяются предки ATMBuildBitMap и раскрываются почти полные сведения об аргументах, типах и локальных переменных.

Анализ задачи № 1891 (CVE-2019-8042)

Сбой TrueType из задачи 1891 разрешается следующим образом:

Недопустимый адрес 0x0a68d4cc находится ровно на 56 124 байта ниже pPrivateFontSpace по адресу 0x0a69b008. Исследование второго аргумента объясняет причину:

Беззнаковые поля содержат отрицательные смещения. Дизассемблирование подтверждает, что fsg_QueryTwilightElement прибавляет первое из них к pPrivateFontSpace, получая адрес сбоя. Отсюда исследователь может проследить происхождение выходящих за диапазон значений или предоставить поставщику этот точный диагноз.

Заключение

Отладочные метаданные способны преобразить исследование приложения с закрытым исходным кодом. Новые обнаруженные символы Reader улучшают обратную разработку, сортировку сбоев и анализ коренных причин в Adobe и других продуктах с общим кодом CoolType.

Такая разведка была бы не нужна, если бы поставщики по умолчанию публиковали символы. Общедоступные службы символов выравнивают возможности защитников и хорошо обеспеченных ресурсами наступательных исследователей, заменяют сокрытие доступностью для исследования и в конечном счёте повышают безопасность клиентского ПО.

Команда Chrome попросила Project Zero исследовать серьёзный сбой, иногда наблюдавшийся в сборках Android. Некоторое время он воспроизводился на ClusterFuzz тестом со ссылкой на внешний сайт, но затем перестал. Возникло опасение, что сайт намеренно активирует уязвимость, хотя в итоге это оказалось не так.

Доступная трассировка AddressSanitizer показывала запись за границы кучи с данными, похожими на сетевые. Сетевой код Chrome был перенесён в служебный процесс, но его строгая изоляция ещё не завершилась. Поэтому ошибка могла дать и первоначальное выполнение кода, и выход из песочницы Chrome.

Серия показывает сложность понимания уязвимости в большой кодовой базе. Решающей оказалась настойчивость, а не внезапное озарение.

Глава 1: тестовый пример

Фаззер создал необычно обычную страницу:

Она всего лишь загружает два сайта, возможно случайно имитируя поведение пользователя, полезное для нагрузки сетевого стека. К началу расследования сохранился только исходный отчёт ASAN:

Трассировка описывает запись 3 848 байт сетевой службой в выделение размером один байт. Не имея готовой среды разработки Chrome для Android, исследователи начали с исходного кода, ожидая найти несоответствие размера IOBuffer.

Глава 2: HttpCache::Transaction

Обратное прослеживание целевого буфера от SpdyHttpStream::DoBufferedReadCallback указывало на вызов HttpNetworkTransaction::Read с несовпадающими buf и buf_len. Мест вызова было немного, но ни одно не выглядело сразу ошибочным. Поиск в репозитории сбоев Chrome нашёл множество внешне похожих трассировок и отнял неделю, не приблизив к первопричине.

Лучший след в конце концов обнаружился в HttpCache::Transaction::WriteResponseInfoToEntry:

Код обновляет io_buf_len_ до размера сериализованных заголовков ответа, но не меняет существующий read_buf_. В другом месте предполагается, что оба поля описывают одно выделение:

Гипотеза соответствовала однобайтовому буферу и большой записи, но добраться до последовательности было сложно. HTTP-кэш реализует автомат примерно из 50 состояний. Обычно он выполняется один раз во время Start и снова, когда Read получает данные ответа.

Для эксплуатации нужен цикл из состояния Read в обработчик, вызывающий WriteResponseInfoToEntry, а затем обратно в чтение данных без замены read_buf_. Подозрительную функцию вызывают четыре обработчика:

• DoCacheWriteUpdatedPrefetchResponse

• DoCacheUpdateStaleWhileRevalidateTimeout

• DoCacheWriteUpdatedResponse

• DoCacheWriteResponse

Сначала исследователи попытались вручную выполнить поиск в глубину по исходному коду, что оказалось запутанным и склонным к ошибкам. Ниже показаны существенные переходы, служащие основой для части 2.

Определив коренную причину, описанную в части 1, исследователи отправили подробности команде Chrome и вернулись к другим задачам. Позднее они создали эксплойт, чтобы понять, как новая процессная архитектура сетевой службы влияет на возможность эксплуатации.

Результатом стала рабочая цепочка Chrome из одной ошибки, но на неё ушли месяцы и множество неудачных попыток. Ненадёжные примитивы делают обычные ошибки дорогими: можно потратить целый день на отладку подготовки кучи, тогда как веб-сервер просто слушает не тот порт.

Глава 4: эксплойт

Уязвимость записывает контролируемые сетевые данные выбранного размера за пределы выделения кучи. Её основное ограничение состоит в том, что перезаписываемое выделение всегда имеет нулевой размер. TCMalloc помещает его в самый маленький бакет — до 16 байт. В сетевом процессе мало полезных объектов такого размера, а IPC постоянно создаёт шум в том же бакете.

Одно из преимуществ состоит в том, что сетевой сервис после сбоя незаметно перезапускается, позволяя повторять попытки эксплуатации.

NetToMojoPendingBuffer

Каждый URLLoader::ReadMore создаёт этот 16-байтный объект, а сервер может влиять на время его жизни, задерживая части ответа:

Недопустимый handle_ приводит к раннему возврату вместо сбоя. Следующая часть HTTP записывается через buffer_, предоставляя контролируемое содержимое. К сожалению, базовое хранилище находится в специализированной области общей памяти IPC, а не среди обычных объектов кучи, поэтому частичная перезапись buffer_ не создаёт сразу полезного смешения типов.

Атака на контейнеры STL

Базовые хранилища контейнеров могут занимать произвольные размерные классы. Вставка первого указателя в пустой std::vector выделяет один слот размером с указатель, а последующий рост удваивает ёмкость. Поэтому точно контролируемые вставки могут поместить указатель в уязвимый 16-байтный бакет и позволить частичную перезапись.

WatcherDispatcher

Перспективный кандидат обнаружился в WatcherDispatcher из Mojo:

base::flat_map использует вектор. watched_handles_ обычно содержит один 16-байтный элемент, поэтому ошибка может перезаписать его указатель Watch. Объект Watch имеет размер 104 байта, что ограничивает возможные смешения типов соседними размерными классами TCMalloc.

Вместо этого можно распылить контролируемые 104-байтные буферы вокруг настоящего Watch и перезаписать лишь младший байт указателя. Поддельный объект, у которого первое слово равно счётчику ссылок 1, а остальное содержимое нулевое, переживает уничтожение и освобождает распылённый буфер. Если этот буфер стоял в очереди на передачу, его последующее повторное использование способно раскрыть указатели списка свободных элементов или объектов.

WebSocket предоставляет двоичные буферы с малыми накладными расходами, время жизни которых удалённый получатель может продлевать, заполняя буфер отправки сокета ОС. Они дают полезное распыление, хотя все поставленные в очередь кадры одного соединения освобождаются вместе.

Эта цель оказалась ненадёжной: одна из двух карт немедленно вызывает сбой через RemoveWatcherRef, каждый диспетчер создаёт шум в куче, а к началу объектов ведут лишь несколько из 16 возможных значений младшего байта указателя.

WebSocketFrame

При отправке данных WebSocket используются две очереди кадров:

Когда сокет насыщен, новые кадры попадают в data_to_send_next_. Базовое хранилище его вектора становится чистой 16-байтной целью. Насыщение зависит от сети и конфигурации системы; эксплойт вручную калибрует FRAMES_ENOUGH_TO_FILL_BUFFER, уменьшает серверный SO_RCVBUF и отключает сжатие.

WebSocketFrame имеет размер 32 байта. Каждое желаемое распылённое выделение также создаёт два нежелательных 32-байтных выделения, поэтому сначала лишь около трети бакета содержит нужный тип. Тем не менее возможных значений младшего байта указателя меньше, а целевой 16-байтный бакет значительно тише, чем при использовании WatcherDispatcher.

Шаблоны выделений

WebSocket::send выполняет для эксплойта три задачи:

• Распыляет 32-байтные буферы рядом с указателем на кадр, который предстоит перезаписать.

• Вставляет целевой элемент вектора и выделяет его WebSocketFrame.

• Повторно занимает освобождённое распылённое выделение объектом IOBuffer.

Перезапись элемента вектора превращает исходное переполнение в освобождение выбранного атакующим 32-байтного выделения. Поскольку вектор владеет кадрами через unique_ptr, поддельному кадру не нужен счётчик ссылок; достаточно, чтобы его указатель data был нулевым.

Утечка информации

Если повреждённый кадр освобождает базовое хранилище уже поставленного в очередь на передачу IOBuffer, позднее сервер получает всё, что повторно заняло это выделение. Замещение другим 32-байтным IOBuffer раскрывает и его таблицу виртуальных функций, и указатель на базовое хранилище. Таблица виртуальных функций раскрывает базу бинарного файла Chrome, а адрес базового хранилища определяет контролируемые атакующим данные кучи.

Базовое выделение может использовать тихий класс большего размера, чтобы не мешать подготовке 16- и 32-байтных объектов.

Выполнение кода

Второе повреждение может освободить либо IOBuffer, либо WebSocketFrame. Замещающий объект спроектирован так, чтобы работать в обоих случаях. Если он замещает IOBuffer, уменьшение поддельного счётчика ссылок вызывает виртуальный метод через поддельную таблицу виртуальных функций. Если он замещает кадр, уничтожение освобождает его элемент data, который указывает на второй поддельный IOBuffer и достигает того же виртуального вызова.

Ранее раскрытое крупное выделение нельзя использовать повторно напрямую, поскольку раскрывший его объект уже освобождён. Сначала эксплойт заполняет этот тихий бакет чередующимися буферами двух WebSocket. Закрытие одного соединения создаёт пустоты рядом с буферами другого. После утечки адреса закрытие второго позволяет заместить известное соседнее выделение поддельной таблицей виртуальных функций, полезной нагрузкой повторного использования кода и поддельным IOBuffer.

Второй запуск уязвимости создаёт использование после освобождения одного из двух совместимых типов объектов и передаёт управление полезной нагрузке.

Состав компонентов

Доказательство концепции состоит из следующих частей:

• serv.py: специальный HTTP-сервер, возвращающий запускающую ошибку последовательность ответов.

• pywebsocket.diff: отключает сжатие и задаёт серверный SO_RCVBUF.

• get_chrome_offsets.py: использует Frida для сбора смещений полезной нагрузки.

• CrossThreadSleep.py: пробуждаемые задержки для потоков сервера WebSocket.

• exploit/echo_wsh.py: управляет синхронизированными и пробуждаемыми задержками сокета.

• exploit/wake_up_wsh.py: пробуждает задержанные echo-соединения.

• exploit/exploit.html: координатор эксплойта на JavaScript.

• get_chromium.sh: извлекает и настраивает уязвимую ревизию Chromium.

• get_pywebsocket.sh и run_pywebsocket.sh: подготавливают и запускают сервер WebSocket.

Сервер WebSocket раздаёт exploit.html; второй HTTP-сервер предоставляет ответ с изображением, запускающий ошибку состояния кеша.

Глава 5: более надёжный эксплойт

Первая версия создаёт множество нежелательных выделений и зависит от повторного попадания в правильные типы. Один запуск занимает около минуты и имеет низкую вероятность успеха.

Подготовка кучи с помощью cookie

Сетевой процесс Chrome также хранит и сохраняет HTTP-cookie. Операции JavaScript с cookie сравнительно легковесны и могут быть объединены в три дополнительных примитива манипуляции кучей.

Даже примитив, предназначенный лишь для добавления одного 32-байтного элемента в список свободных, имеет сложную трассировку выделений:

Несмотря на шум, эти операции разделяют желательные и нежелательные 32-байтные выделения и очищают область распыления.

В худшем случае перезапись младшего байта теперь оставляет исходный указатель неизменным. Полезны семь из восьми значений байта вместо двух из восьми, что повышает оценочную вероятность успеха одного запуска примерно до 0,75.

Cookie накладывают ограничения: сайт ограничен 180 cookie, каждая 512-я операция сбрасывает хранилище на диск, автоматический сброс происходит каждые 30 секунд, а каждому распылению необходимо известное исходное состояние cookie. Разделение распыления на небольшие независимо обрабатываемые части позволяет обойти большинство ограничений. С учётом перезапусков сетевого процесса окончательный эксплойт обычно срабатывает за две или три попытки.

Глава 6: заключение

Перенос сетевого кода в отдельный сервисный процесс сократил число доступных типов объектов и механизмов подготовки кучи. Даже до строгой изоляции эта более узкая функциональность усложнила эксплуатацию по сравнению с монолитным процессом браузера.

В то же время незаметный перезапуск службы помогает атакующим: неограниченное число попыток делает ненадёжные примитивы жизнеспособными, особенно на платформах без индивидуальной для процессов рандомизации. Здесь намеренно использовался Linux, чтобы эксплойту пришлось построить стабильную утечку информации.

Эта цепочка сложнее и хуже сопровождается, чем традиционное сочетание компрометации отрисовщика с повышением привилегий через ОС или ядро, поэтому вряд ли стала бы первым выбором атакующих. Тем не менее она доказывает, что ошибку сетевого стека можно эксплуатировать с приемлемой надёжностью, и подтверждает необходимость изолировать менее заметные поверхности атаки браузера.

В предыдущей гостевой статье «Нарушение потока данных» выполнение в процессе отрисовки было получено через V8. Такой процесс по-прежнему изолирован от операционной системы, а благодаря Site Isolation — и от процессов отрисовки других сайтов. В этой статье RIDL и связанные микроархитектурные атаки используются для утечки секретов маршрутизации Mojo, вызова привилегированных интерфейсов, чтения локальных файлов и создания исполняемого пакетного файла за пределами песочницы Windows.

Процессы отрисовки имеют ограниченный доступ к ядру благодаря таким механизмам, как seccomp в Linux и блокировка win32k в Windows. Тем не менее им нужны привилегированные службы для таких задач, как загрузка изображения. Стандартный IPC-фреймворк Chrome, Mojo, создаёт языковые привязки из определений интерфейсов .mojom и поддерживает передачу конечных точек по существующим каналам.

Mojo соединяет узлы уровня процессов через зависящие от платформы каналы сообщений. Узел-брокер помогает устанавливать каналы и выполняет операции, запрещённые песочницей. Отдельные конечные точки IPC представляют собой порты:

peer_node_name и peer_port_name — случайные 128-разрядные идентификаторы. Сообщение направляется своему узлу, после чего узел назначения находит локальный порт и помещает сообщение в очередь.

Знание этих идентификаторов является правом доступа. Как отмечено в документации по безопасности Mojo, любой узел может отправить сообщение любому порту, если знает оба имени. Поэтому утечка информации из процесса браузера может раскрыть привилегированную конечную точку. Например, целочисленное переполнение blob из проблемы Chromium 779314 позволяло процессу отрисовки читать предшествующую память кучи браузера, искать правдоподобные структуры портов и внедрять сообщения.

RIDL, одна из атак Microarchitectural Data Sampling, обеспечивает межпроцессную утечку из внутренних буферов ЦП. Хотя меры защиты ОС и микрокода очищают затронутые буферы при переключении в менее привилегированный контекст, одновременно выполняющиеся потоки одного физического ядра всё ещё могут взаимодействовать, когда включён Hyper-Threading. Описание основных техник см. в локальной ridl.pdf (файл в files/ridl.pdf).

Варианты MDS различаются тем, нацелены ли они на загрузки или сохранения, должен ли секрет покинуть L1, насколько точно можно выбрать позицию строки кеша и какова пропускная способность. Все они вероятностные, поэтому подходящая цель должна многократно обращаться к секрету.

Microarchitectural Fill Buffer Data Sampling (MFBDS)

Первый эксплойт нацелен на буфер заполнения строк ЦП. Его основная транзакция:

Измерение времени доступа к страницам пробного массива раскрывает выбранный байт. Изменение начального адреса выбирает смещение внутри строки кеша. Фильтрация по префиксу или суффиксу сокращает число посторонних образцов. Этот вариант наблюдает только отсутствующие в L1 значения, поэтому между попытками эксплойт должен вытеснять секрет.

Первая цель — привилегированный URLLoaderFactory. Фабрики, принадлежащие процессам отрисовки, обеспечивают политику одного сайта, а принадлежащие браузеру могут её игнорировать и передавать локальные файлы. Утечка имени одного привилегированного порта позволяет подделать запрос, который отправит /etc/passwd на подконтрольный атакующему сервер.

Чтобы заставить браузер многократно обращаться к такому порту, атака нацеливается на поиск в узле Mojo:

Отправка сообщения несуществующему порту заставляет узел искать его в ports_. Если случайное имя попадает в тот же сегмент хеш-таблицы, что и привилегированный порт, таблица читает полный хеш кандидата. Имя порта находится в той же строке кеша, а MFBDS может выбрать всю строку, хотя код напрямую не читал каждый байт.

Свежий узел Chrome имеет около 700 сегментов, а выравнивание добавляет четыре возможных положения строки кеша. Service workers с предварительной загрузкой навигации делают полный перебор практичным: каждая приостановленная навигация верхнего уровня создаёт привилегированный загрузчик. Тысячи iframe с задерживаемыми сервером запросами одновременно сохраняют тысячи целей. Дополнение каждого пробного сообщения 32 КиБ также обычно вытесняет прежнее содержимое L1.

Таким образом, эксплойт для Linux выполняет следующие действия:

1. Компрометирует процесс отрисовки.

2. Запускает процесс выборки RIDL на всех логических ЦП, кроме одного, используя разные смещения строк.

3. Устанавливает service worker с предварительной загрузкой навигации.

4. Создаёт множество iframe и приостанавливает их сетевые запросы.

5. Отправляет случайные имена портов назначения сетевому процессу.

6. При совпадении сегмента извлекает порт привилегированного загрузчика.

7. Подделывает запрос URLLoaderFactory, отправляющий локальный файл.

TSX Asynchronous Abort (TAA)

Среди новых вариантов MDS, опубликованных в ноябре 2019 года, было более быстрое доказательство концепции TAA. Вариант VUSec нацелен на сохранения и потенциально устраняет необходимость явного вытеснения из кеша, когда жертва записывает секрет по меняющимся адресам.

Сообщение из браузера NetworkService содержит секретный порт назначения, перед которым указано имя его узла, что предоставляет удобный фильтр RIDL. Процесс отрисовки может многократно провоцировать такие сообщения через NetworkService.OnPeerToPeerConnectionsCountChange: создать поддельное соединение WebRTC и переключать его состояние между подключённым и отключённым.

После утечки порта NetworkService поддельный запрос может создать NetworkContext и выбрать путь к его базе данных cookie SQLite. Этот кажущийся ограниченным примитив записи файлов превращается в выполнение кода в Windows, поскольку пакетные файлы игнорируют произвольные начальные байты до следующего CRLF. Атакующий выбирает путь автозапуска, например cookies.bat, а затем добавляет cookie с переводом строки и командой.

Эксплойт для Windows выполняет следующие действия:

1. Компрометирует процесс отрисовки.

2. Запускает процессы выборки TAA/RIDL на всех логических ЦП, кроме одного, меняя смещения строк кеша.

3. Создаёт поддельное соединение WebRTC и многократно переключает состояние подключения.

4. Извлекает порт NetworkService из операций сохранения IPC браузера.

5. Подделывает CreateNetworkContext с путём базы данных cookie в каталоге автозапуска пользователя, например cookies.bat.

6. Добавляет cookie, содержащий \r\ncalc.exe\r\n.

7. Ждёт следующего входа пользователя в систему.

Доказательство концепции в среднем выполнялось за одну-две минуты и на тестовой машине стабильно завершалось менее чем за пять минут. Другие варианты, например MLPDS, могут быть быстрее.

Выводы

В общедоступных рекомендациях MDS часто описывалась как устранённая современным программным обеспечением, а отключение Hyper-Threading упоминалось лишь в примечании. Такая формулировка может скрыть практические последствия сохранения включённых соседних аппаратных потоков.

Утечка информации — это не просто обход ASLR. Секретные порты Mojo представляют права доступа; среди других привлекательных целей — значения UnguessableToken Chrome, cookie аутентификации и данные посторонних процессов. Поэтому аппаратные уязвимости могут нарушать программные границы безопасности, даже когда в соответствующем пути целевого приложения нет обычной ошибки безопасности памяти.

Во вторник обновлений за декабрь 2019 года вошла CVE-2019-1458 — уязвимость повышения привилегий Win32k, эксплуатировавшаяся в реальных атаках и обнаруженная «Лабораторией Касперского». Компания опубликовала подробности эксплойта, но лишь частичные сведения о коренной причине. Без доступа к образцу для анализа вариантов сначала требовалось восстановить уязвимость по двоичному патчу.

Сравнение патчей важно для раскрытия уязвимостей, поскольку обновление делает изменённый машинный код публичным, даже если примечания к выпуску остаются расплывчатыми. Опытные исследователи могут сравнить старые и новые бинарные файлы и иногда понять исправление раньше, чем защитники завершат его развёртывание.

Это исследование за три недели привело к рабочему доказательству концепции, вызывающему сбой, хотя до начала работы у меня не было опыта исследований Windows. Оно также восстановило не ту уязвимость: CVE-2019-1433, исправленную в ноябре, вместо применявшейся в реальных атаках CVE-2019-1458, исправленной в декабре. Сама ошибка документирует реалистичный процесс анализа патчей и полезную верхнюю оценку времени превращения обновления Windows в доказательство концепции.

Мой процесс

CVE-2019-1458 затрагивала Windows 7 и Windows 10 и находилась в основном компоненте ядра графического интерфейса Win32k. Джеймс Форшоу посоветовал начать с Windows 7, поскольку она использует один монолитный win32k.sys, содержит меньше шума от Control Flow Guard и инструментирования и позволяет не разбираться с разделением Windows 10 на win32k.sys, win32kfull.sys и win32kbase.sys.

Виртуальную машину Windows 7 SP1 x64 обновили по сентябрь 2019 года, сделали снимок, а затем установили обновления по декабрь. Два образа win32k.sys стали входными данными сравнения. Решающей ошибкой было предположение, что отображаемый Центром обновления сентябрьский пакет являлся последним перед декабрём. Ноябрьский пакет существовал в каталоге Центра обновления Майкрософт, но не отображался. Сравнение ноября с декабрём выделило бы CVE-2019-1458; сравнение сентября с декабрём включило CVE-2019-1433.

На одной виртуальной машине работал WinDbg, а её клон служил целью отладки ядра.

Сравнение патчей Windows 7 win32k.sys

Сначала BinDiff нашёл во всём драйвере лишь 23 изменённые и две новые функции. Правильное сравнение ноября с декабрём показало бы всего пять изменённых функций.

Сервер символов Microsoft обнаружился после первого прохода. Сначала имена из вывода x win32k!* в WinDbg применялись вручную после перебазирования баз IDA. Позднее IDA в Linux настроили на получение сведений PDB через виртуальную машину Windows.

Исследование не тех изменений

GreGetStringBitmapW сначала выглядела перспективно, поскольку «Лаборатория Касперского» упоминала использование растровых изображений. В одной изменённой вызываемой функции, не названной в открытых символах, появилась проверка аргументов перед вычислением смещения записи в буфер.

Связь оказалась поверхностной. Перекрёстные ссылки показали, что NtGdiGetStringBitmapW достижима только через GetStringBitmapA в gdi32.dll, а не через функции переключения задач, описанные «Лабораторией Касперского».

Первая тестовая программа рабочего стола Windows вызывала CreateBitmap, SetBitmapBits, NtUserMessageCall и переключение задач под точкой останова ядра. Функция так и не выполнилась. Тем же способом исключили GreAnimatePalette.

Сужение различий до xxxNextWindow и xxxKeyEvent

Процесс развернули: начали с названной «Лабораторией Касперского» функции DrawSwitchWndHilite, а затем искали изменённые функции среди вызывающих её. xxxNextWindow находилась на два вызова выше, вызывалась только из xxxKeyEvent, а весь изменённый код в xxxKeyEvent окружал этот вызов.

ReactOS предоставила недостающие сведения о типах. Помогли и соглашения об именовании Windows: gpqForeground означает глобальный указатель на очередь (tagQ *), а gptiCurrent — глобальный указатель на сведения о потоке (tagTHREADINFO *). Затем dt win32k!tagQ в WinDbg раскрыл структуру очереди.

Декабрьская версия xxxNextWindow добавила одну проверку флага в первом аргументе tagQ *. Если он установлен, функция завершается до использования очереди. Чтобы доказать важность этого флага, пришлось проследить пользовательские callback-функции и блокировку объектов на уровне дизассемблированного кода.

Хронология

• Декабрь 2019 года: объявлено, что CVE-2019-1458 эксплуатируется в реальных атаках.

• Три рабочих недели: настройка среды Windows, сравнение бинарных файлов, обратная разработка и доказательство концепции, вызывающее сбой.

• Январь 2020 года: черновик ошибочно определяет восстановленную ошибку как CVE-2019-1458.

• Предварительный просмотр поставщиком: Microsoft указывает на InitFunctionTables, раскрывая, что анализируемый патч относится к CVE-2019-1433.

• Март 2020 года: Пётр Флорчик публикует настоящие анализ и PoC CVE-2019-1458.

Анализ коренной причины CVE-2019-1433

Класс ошибки: использование после освобождения.

xxxKeyEvent передаёт tagQ * в xxxNextWindow. Изначально ни одна функция не блокировала очередь на время callback-вызовов. xxxMoveSwitchWndHilite вызывает пользовательский режим, где контролируемый атакующим код может уничтожить очередь. Позднее xxxNextWindow без проверки разыменовывает устаревший указатель.

Исследованные образцы Запуск xxxNextWindow

Доказательство концепции использует SendInput для создания специальной последовательности «залипающего» переключателя задач:

Обычные ALT+TAB и «залипающая» комбинация ALT+CTRL+TAB показывают другой переключатель и не входят в xxxNextWindow.

Первое нажатие Tab рисует переключатель и не уязвимо. Последующее нажатие перемещает выделение и достигает пути callback-функции.

Освобождение очереди

Уязвимая логика приблизительно выглядит так:

xxxMoveSwitchWndHilite в итоге вызывает xxxSendMessageTimeout для выделенного окна. Она отправляет недокументированное сообщение WM_LPKDRAWSWITCHWND (0x8c), распределяемое в пользовательском режиме через ntdll!KiUserCallbackDispatcher к user32!_fnINLPKDRAWSWITCHWND.

Доказательство концепции на лету исправляет PEB.KernelCallbackTable, чтобы выполнить собственную callback-функцию. Внутри неё AttachThreadInput присоединяет обработку ввода одного потока к другому и уничтожает старую очередь, освобождая tagQ, на которую всё ещё ссылается xxxNextWindow.

Callback-функция также уничтожает следующее выделенное окно, поэтому HMValidateHandleNoSecure возвращает ноль. На следующей итерации одно из условий проверки окна переключения принудительно завершается ошибкой, устанавливая switch_data в null. Затем выполнение достигает use_queue и разыменовывает освобождённую очередь.

Windows 10

CVE-2019-1433 также затрагивала Windows 10 1903:

При включённом Driver Verifier то же доказательство концепции вызывает ошибку в win32kfull!xxxNextWindow+0x743 при разыменовании освобождённой очереди. Windows 10 потребовала другой последовательности клавиш и индекс таблицы callback-функций 0x61 вместо 0x57. Рабочий сбой удалось адаптировать примерно за три часа; он срабатывал приблизительно в одном из трёх запусков.

Исправление уязвимости

Microsoft изменила четыре функции:

• xxxNextWindow

• xxxKeyEvent в Windows 7 или EditionHandleAndPostKeyEvent в Windows 10

• zzzDestroyQueue

• новую UnlockQueue

Исправление одновременно предотвращает немедленное освобождение используемой очереди и записывает попытку уничтожения в течение заблокированного интервала.

zzzDestroyQueue

Если tagQ.cLockCount больше нуля, исправленный деструктор не может освободить очередь и вместо этого устанавливает бит в tagQ.QF_flags.

Перед использованием устаревшего указателя xxxNextWindow проверяет бит флага 0x1a:

Если была попытка уничтожения, функция завершается. В противном случае очередь остаётся действительной, и выполнение продолжается.

xxxKeyEvent / EditionHandleAndPostKeyEvent

Теперь вызывающая функция блокирует очередь на уровне потока на время xxxNextWindow. Потоковая блокировка добавляет объект в список блокировок потока и увеличивает его счётчик ссылок. После вызова новая UnlockQueue отменяет эту операцию.

Windows 10 получила ту же стратегию из трёх частей: добавить UnlockQueue, установить блокировку вокруг xxxNextWindow и проверять флаг уничтожения перед повторным использованием очереди.

Заключение

Исследование восстановило CVE-2019-1433, а не CVE-2019-1458. Прямое сравнение сентября с декабрём включило исправления лишнего месяца; предварительный просмотр Microsoft раскрыл несоответствие. Проверка каждого промежуточного обновления и каталога Центра обновления Майкрософт предотвратила бы ошибку.

Результат всё равно полезен. Исследователь с опытом обратной разработки, но новичок в Windows, прошёл путь от начальной настройки виртуальной машины до доказательства концепции, вызывающего сбой, за три недели. Атакующим, сравнивающим патчи в поиске любой пригодной для эксплуатации ошибки, а не конкретной CVE, вряд ли важно, что первая жизнеспособная уязвимость оказалась не той, которую они ожидали. Поэтому три недели — правдоподобная высокая верхняя оценка такой работы для квалифицированного специалиста.

Популярные приложения для обмена сообщениями часто расшифровывают входящее изображение и создают UIImage ещё до какого-либо взаимодействия с пользователем:

Затем код уведомлений отрисовывает миниатюру:

Так разбор изображений Apple и отрисовка CoreGraphics становятся поверхностью атаки без взаимодействия с пользователем. Методы эксплуатации, разработанные в статье «Удалённая эксплуатация iPhone, часть 1», показывают, что ошибка повреждения памяти может привести к выполнению кода, если тот же процесс отправляет подтверждения доставки, некоторые отображения используют ASLR на время одной загрузки, а служба автоматически перезапускается. Оракул сбоев может восстановить сведения о расположении памяти до того, как поддельные объекты Objective-C или связанные примитивы перенаправят выполнение.

Поскольку UIImage автоматически определяет все поддерживаемые платформой форматы, первая задача — выявить их полный набор.

Знакомство с ImageIO.framework

UIImage делегирует разбор ImageIO. Для каждого формата существует подкласс IIO_Reader с методом testHeader. Реализация LibJPEG просто проверяет сигнатуру:

Перечисление этих реализаций показывает поддерживаемые модули чтения:

PICT и SGI поддерживаются только в macOS. Помимо JPEG, PNG, GIF и TIFF присутствуют менее распространённые форматы текстур, например KTX и ASTC, данные Adobe Illustrator и форматы Apple, такие как ICNS и, вероятно, ATX для Animoji.

Некоторые модули чтения используют открытые библиотеки, включённые в каталог Resources библиотеки ImageIO: libGIF, libJP2, libJPEG, libOpenEXR, libPng, libRadiance и libTIFF. Для других форматов существуют лишь ограниченные реализации. Некоторые из них, включая PSD, в macOS могут декодироваться процессом ImageIOXPCService, однако общедоступные API не позволяют вызывающей стороне потребовать такую изоляцию.

Фаззинг парсеров изображений с закрытым исходным кодом

Большая часть целевого кода имеет закрытые исходники. Кроме того, в эксперименте намеренно использовался только один Mac Mini, поэтому требовалась инструментация с небольшими накладными расходами и управлением по покрытию. Получившийся подход TrapFuzz был реализован поверх Honggfuzz и вдохновлён работой Full-speed Fuzzing: Reducing Fuzzing Overhead through Coverage-guided Tracing.

1. Сценарий IDAPython перечисляет смещения начала каждого базового блока.

2. При запуске процесса первый байт каждого ещё не обнаруженного блока заменяется на int3 в Intel.

3. Теневая память хранит каждый исходный байт и его позицию в битовой карте покрытия.

4. Обработчик SIGTRAP определяет блок, отмечает его покрытым, восстанавливает байт и продолжает выполнение.

Каждая точка останова выполняется только один раз, поэтому по мере роста покрытия накладные расходы приближаются к нулю. Компромисс заключается в покрытии базовых блоков, а не переходов. Разные переходы в один блок выглядят одинаково, в отличие от AFL или SanitizerCoverage. Динамическая бинарная инструментация может восстановить покрытие переходов, но увеличивает стоимость выполнения; см. локальную презентацию 2019-04-19-fuzzing-binaries-using-dynamic-instrumentation.pdf (файл в files/2019-04-19-fuzzing-binaries-using-dynamic-instrumentation.pdf).

При равном числе итераций такой более грубый сигнал может найти меньше ошибок, но подходит для быстрой оценки надёжности парсеров. Разработчики, имеющие доступ к исходному коду, по-прежнему располагают лучшими возможностями для исчерпывающего непрерывного фаззинга. Патчи TrapFuzz и инструменты IDAPython доступны в репозитории p0tools.

После нескольких недель работы с исходным набором примерно из 700 изображений поддерживаемых форматов были обнаружены:

• Проблема P0 1952: использование libTIFF в ImageIO записывает управляемые данные за пределами буфера кучи. CVE не назначена, вероятно, потому, что Apple уже обнаружила ошибку самостоятельно.

• CVE-2020-3826 / проблема 1953: чтение за пределами кучи при обработке изображений DDS с недопустимыми размерами.

• CVE-2020-3827 / проблема 1956: запись за пределами кучи в оптимизированном парсере JPEG.

• CVE-2020-3878 / проблема 1974: вероятная ошибка на единицу при декодировании PVR, записывающая дополнительную строку пикселей за пределами выходного буфера.

• CVE-2020-3878 / проблема 1984: связанное чтение за пределами PVR, вероятно имеющее ту же первопричину.

• CVE-2020-3880 / проблема 1988: чтение за пределами памяти в обработчике включённой библиотеки OpenEXR.

OpenEXR

OpenEXR — открытый формат изображений с широким динамическим диапазоном и парсер на C/C++. ImageIO делает его доступным для входных данных приложений обмена сообщениями без взаимодействия с пользователем и, вероятно, для других автоматических процессов обработки медиафайлов.

Доступность исходного кода позволила применить обычный фаззинг с управлением по покрытию переходов. Внутренний фаззер Google использовал LLVM SanitizerCoverage, обычные бинарные мутации, около 80 начальных изображений, примерно 500 ядер и две недели времени выполнения. Восемь предположительно уникальных уязвимостей были совместно зарегистрированы как проблема Project Zero 1987 и исправлены в OpenEXR 2.4.1:

• CVE-2020-11764: запись пикселей за пределами кучи в copyIntoFrameBuffer.

• CVE-2020-11763: чтение за пределами std::vector с последующей записью через недопустимый слот элемента.

• CVE-2020-11762: memcpy за пределами памяти, потенциально с недопустимыми как источником, так и назначением.

• CVE-2020-11760, CVE-2020-11761 и CVE-2020-11758: чтения за пределами памяти, связанные с пикселями и внутренними структурами.

• CVE-2020-11765: чтение за пределами стека, вероятно после того, как перезапись на единицу удалила завершающий символ строки.

• CVE-2020-11759: вероятное целочисленное переполнение, приводящее к записи через неконтролируемый указатель.

Сбой ImageIO из проблемы 1988 не воспроизводился в актуальной OpenEXR. Возможно, Apple поставляла более старую версию, в которой ошибка сохранялась после того, как её уже исправили в основном проекте.

Рекомендации

Разбор медиафайлов остаётся постоянной поверхностью удалённой атаки. Производителям и разработчикам следует непрерывно фаззить каждый парсер входных данных. Такие фреймворки, как ImageIO, должны позволять вызывающим сторонам задавать список разрешённых форматов и выбирать декодирование в отдельном процессе.

Приложениям обмена сообщениями следует принимать для предварительного просмотра без взаимодействия лишь небольшой набор форматов. Всё остальное отправитель может перекодировать до передачи. Для ImageIO это сокращает поверхность на стороне получателя примерно с 25 парсеров до нескольких.

Заключение

Парсеры изображений операционной системы и сторонних разработчиков становятся поверхностью атаки без взаимодействия с пользователем, когда приложения обмена сообщениями автоматически создают миниатюры. Умеренная кампания фаззинга закрытого кода обнаружила несколько ошибок безопасности памяти, а более крупная кампания OpenEXR с управлением по исходному коду нашла ещё восемь.

Автоматический перезапуск службы может предоставить достаточно попыток, чтобы превратить некоторые из этих дефектов в удалённое выполнение кода. Поэтому непрерывный фаззинг, изоляция процессов и решительное сокращение числа форматов — взаимодополняющие обязательные требования, а не необязательные усиления защиты.

При разработке эксплойта обнаружился отдельный недостаток: один процесс содержимого Firefox мог открыть другой с полным доступом. Он оставался эксплуатируемым даже после исправления назначения токенов Microsoft. Project Zero зарегистрировала его как проблему 2016, а Mozilla — как ошибку 1618911. В Firefox этот профиль содержимого назывался уровнем 5, или L5.

Первопричина

В браузерах на основе Chromium обычно существует единственный процесс GPU, тогда как процессы отрисовки содержимого изолированы строже. Firefox повторно использовал политику L5 уровня GPU для множества равноправных процессов содержимого. Основным средством контроля служит ограниченный токен, DACL по умолчанию которого предоставляет:

Токен USER_LIMITED оставляет текущего пользователя, BUILTIN\Users, Everyone, Interactive и SID сеанса входа включёнными группами. Кроме того, он добавляет BUILTIN\Users, Everyone, Restricted и SID сеанса входа в список ограничивающих SID. Проверка доступа ограниченного токена Windows должна пройти для обоих списков. Группа текущего пользователя проходит обычную проверку, а SID Restricted — ограничивающую, что предоставляет полный доступ к процессам и потокам всех равноправных участников L5.

Окно запуска

После создания процесса его основной токен нельзя заменить токеном с иным набором ограничений. Поэтому Chromium запускает процесс песочницы с ограниченным основным токеном, но на время начальной подготовки назначает его первому потоку более привилегированный токен олицетворения.

Для L5 токен USER_RESTRICTED_SAME_ACCESS не отключает обычные группы и добавляет каждую из них как ограничивающий SID. Он почти эквивалентен обычному токену, оставаясь при этом формально ограниченным, что требуется Windows при ограниченном основном токене. После инициализации LowerToken снимает олицетворение.

Между запуском процесса и LowerToken новый процесс содержимого фактически находится вне песочницы, за исключением низкого уровня целостности. Если уже взломанный процесс содержимого откроет и захватит его в этот промежуток, атакующий унаследует возможности подготовительного токена.

Firefox часто запускает новые процессы содержимого, например при открытии вкладок. Атакующий может дождаться запуска или, вероятно, спровоцировать его, а затем получить полный контроль через разрешающий DACL равноправного процесса. В отличие от прежней цепочки Chrome, более мощный подготовительный токен может напрямую открыть внепроцессный COM-сервер. Перебирать COM-потоки не требуется, а эксплойт не покидает модель ограниченных токенов и не зависит от ошибки ядра Microsoft.

Разработка исправления

Очевидной защитой был SetLockdownDefaultDacl, удаляющий Restricted и SID сеанса входа из DACL по умолчанию. Этот параметр появился после более раннего выхода из песочницы GPU, но включался только в песочницах процессов отрисовки.

За год до этого Никлас Баумстарк сообщил о доступе между равноправными процессами Firefox. Включение блокировки нарушило кэширование DirectWrite, воспроизведение звука и производительность. Службы Windows RPC часто олицетворяют клиента и открывают его процесс:

Обычные приложения могут обращаться к собственному процессу, поэтому такое предположение службы разумно. Глобально заблокированный DACL запрещает и доступ равноправных процессов, и доступ к себе. Код внутри процесса обычно избегает проблемы, используя псевдодескриптор текущего процесса, но службы RPC выполняют настоящую проверку доступа. В прежнем отчёте отсутствовала полная цепочка выхода, а цена совместимости остановила исправление.

Новая защита должна была:

1. Позволить каждому процессу и его RPC-службам открывать сам процесс и его потоки.

2. Запретить доступ всем остальным процессам того же уровня песочницы.

3. Полностью работать в обычном пользовательском режиме, без административных обратных вызовов ядра.

Список ограничивающих SID может содержать SID, отсутствующие среди обычных групп токена. Теперь песочница создаёт случайный SID для каждого процесса, вставляет его и в ограничивающий список токена, и в DACL по умолчанию, а затем применяет SetLockdownDefaultDacl.

При доступе к себе SID текущего пользователя проходит обычную половину проверки, а уникальный случайный SID — ограничивающую. Другой процесс L5 имеет иной случайный SID: обычная проверка по-прежнему проходит, но ограничивающая завершается отказом. Олицетворение RPC продолжает работать, поскольку служба видит ту же уникальную идентичность токена, что и открываемый процесс.

Реализация вошла в PolicyBase::MakeTokens Chromium, после чего Mozilla интегрировала и испытала её. Firefox 76 выпустил защиту без наблюдавшихся ранее регрессий.

Защита включается явно. Её должен принять каждый равноправный процесс, способный стать трамплином для выхода. Иначе обновлённый Firefox мог бы завершить неисправленный процесс GPU Chrome, дождаться его перезапуска с привилегированным подготовительным токеном и захватить. Поэтому Chromium включил ту же защиту для процесса GPU в M83; она также вошла в Microsoft Edge 83.

Заключение

CVE-2020-12388 превратила обычный доступ между процессами одного уровня в полный выход из песочницы Firefox благодаря гонке с временным токеном олицетворения при запуске Chromium. Для исправления потребовался новый уникальный для процесса SID возможностей вместо общей блокировки ACL, нарушавшей предположения Windows RPC.

В отличие от предыдущей проблемы назначения токена, Firefox и Chromium смогли устранить недостаток без изменения ядра Windows. Тем не менее результат показывает, что безопасность песочницы зависит от поведения каждого взаимодействующего процесса и службы, а не только от номинально ограниченного процесса отрисовки.