В статье описывается исключительно опасное использование после освобождения в процессе браузера Chrome, затрагивавшее Linux, Chrome OS и OS X. В отличие от обычной уязвимости процесса браузера, её можно было запустить непосредственно из веба, не компрометируя сначала процесс отрисовки.

Ошибка была обнаружена во время совместного с Project Zero мероприятия по поиску ошибок IPC Chrome. В ходе той же работы нашли ещё три ошибки.

Общие сведения

Chrome использует множество процессов и потоков. Каждый поток обычно владеет MessageLoop, а работу можно передать другому потоку через интерфейс TaskRunner:

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

Web MIDI предоставляет веб-страницам доступ к MIDI-устройствам. API на стороне процесса отрисовки отправляет сообщения IPC привилегированному коду процесса браузера:

MidiHost одновременно является BrowserMessageFilter и MidiManagerClient; время его жизни связано с процессом отрисовки. Платформенная реализация MidiManager обычно существует всё время работы браузера. В ALSA она владеет send_thread_ и event_thread_. Процесс отрисовки взаимодействует через MidiMessageFilter с помощью следующих сообщений:

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

Ошибка 1: клиент без удержания ссылки

MidiManagerAlsa::DispatchSendMidiData планирует фактическую отправку, а затем передаёт потоку отправки задачу учёта:

Здесь client — это MidiHost. Если процесс отрисовки завершится до выполнения задачи потоком отправки, браузер совершит виртуальный вызов через освобождённый MidiHost. Страница может создать большую очередь, отправив до 10 МБ MIDI-данных, а затем принудительно завершить свой процесс отрисовки. Реализация OS X, по-видимому, содержала ту же ошибку времени жизни.

Ошибка 2: уничтожение одновременно с входными данными

MidiManager::ReceiveMidiData захватывает блокировку и вызывает ReceiveMidiData для каждого зарегистрированного клиента. Реализация MidiHost отправляет сообщение IPC обратно процессу отрисовки. Когда BrowserMessageFilter::Send вызывается вне потока ввода-вывода, он публикует задачу, привязанную к this.

Деструктор MidiHost вызывает EndSession, который захватывает блокировку менеджера и отменяет регистрацию клиента. Это не устраняет гонку: поток событий уже мог войти в ReceiveMidiData и способен опубликовать Send во время уничтожения. Привязка задачи увеличивает счётчик ссылок с нуля, но уничтожение уже началось. В итоге поток ввода-вывода вызывает Send для удалённого MidiHost.

Эта вторая ошибка, вероятно, затрагивала и Windows.

Ошибка 1 была исправлена для ALSA и OS X в Chrome 47.0.2526.106. Ошибка 2 впервые была исправлена в стабильном Chrome 48. Соответствующие изменения: a3d22f60, 54d256d1 и bd648ad6.

Эксплуатация первой ошибки

Доказательство концепции состоит из start.html и haq.html. Щелчок на первой странице открывает вторую в другом процессе отрисовки. Второй процесс отправляет MIDI-данные и закрывается, а первый распыляет выделения в процессе браузера, пытаясь заместить освобождённый MidiHost.

Есть одно осложнение: каждый процесс отрисовки с активным сеансом MIDI получает все входящие MIDI-сообщения. Отражённые сообщения могут занять завершающийся процесс и задержать удаление либо запустить вторую гонку. Сообщения SysEx полезны тем, что Chrome доставляет их только процессам отрисовки с разрешением SysEx. Поэтому первый процесс может заполнить поток событий трафиком SysEx, пока второй, не имеющий разрешения, завершится без обработки отражённой полезной нагрузки. Предоставление разрешения вызывает запрос «Use your MIDI devices». Эксплойт работал и без него, но лишь примерно в одном случае из пяти.

start.html haq.html

Этот файл необходимо раздавать с другого источника, например http://0.0.0.0:8001.

Чтобы запустить доказательство концепции против 64-разрядного Chrome 47.0.2526.80 в Linux, запустим два HTTP-сервера. Два порта не являются строго обязательными, хотя SimpleHTTPServer в этой конфигурации оказался ненадёжным:

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

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

Заключение

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

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

Обработка файловых путей Win32 API в Windows NT — история, полная уловок ради обратной совместимости, странного поведения и красоты. Неправильная работа с путями Win32 может привести к уязвимостям. Эта публикация претендует на роль исчерпывающего руководства по типам путей, поддерживаемым операционной системой. Мы не будем касаться особенностей нижележащих файловых систем, таких как потоки NTFS, а сосредоточимся на уровне преобразования Win32 в NT.

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

Предупреждение: анализ основан на Windows 8.1 и Windows 10. Недокументированные детали могут измениться. Кроме того, речь идёт о прямых вызовах API: некоторые или все приёмы могут не работать через API оболочки или общий ресурс SMB.

Основы связи между путями Win32 и NT

Диспетчер ввода-вывода ядра обрабатывает пути иначе, чем общедоступные API пользовательского режима, такие как CreateFile. Внутри CreateFile вызывает экспортированную из NTDLL функцию RtlDosPathNameToRelativeNtPathName_U, которая преобразует путь Unicode в формате Win32, исторически называемом DOS, в форму NT:

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

NTDLL различает семь типов путей. Определяет их функция RtlDetermineDosPathNameType_U:

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

Этот API также доступен как GetFullPathName. Тестовая программа приведена в конце статьи.

Типы путей DOS

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

1. Преобразовать прямые косые черты (U+002F) в разделители-обратные слеши (U+005C).

2. Свернуть повторяющиеся разделители пути в один.

3. Удалить элементы пути, состоящие из одной точки.

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

5. Сохранить завершающий разделитель пути.

6. Удалить конечные пробелы и точки из последнего элемента, если это не . или ...

В таблицах [space] обозначает пробел.

Абсолютный путь с диском

Эта знакомая и сравнительно однозначная форма содержит диск и хотя бы один элемент пути.

Конечные пробелы и точки исчезают. Никакое количество ссылок на родительские каталоги не может удалить букву диска.

Относительный путь с диском

Относительный путь с диском указывает букву диска, но не содержит разделителя после двоеточия, например C:ABC. Текущий каталог для этого диска выбирается следующим образом:

1. Если диск совпадает с текущим рабочим каталогом, используется этот каталог.

2. В противном случае, если для диска существует переменная среды =?: и она указывает на существующий путь, используется её значение.

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

Предположим, рабочий каталог равен X:\ABC, для диска Y задано =Y:=Y:\DEF, а для диска Z настройки нет:

Хотя SetCurrentDirectory устанавливает только один рабочий каталог процесса, cmd.exe поддерживает отдельные переменные для каждого диска, когда команда cd меняет диск. Они скрыты от большинства инструментов, но видны в дампе PEB отладчика.

Реализация не требует, чтобы «буквы» дисков находились в диапазоне от A до Z: любой путь, второй символ которого является двоеточием, считается абсолютным или относительным путём с диском. Этим объясняется странная запись =::=::\, часто встречающаяся в окружении процессов. Синтаксис объектов оболочки Explorer, например ::{20d04fe0-3aea-1069-a2d8-08002b30309d}, можно передать файловому API, и он будет истолкован как относительный путь для диска с именем :. Затем дочерние процессы наследуют созданную по умолчанию переменную среды.

Корневой путь

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

Относительный путь

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

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

Для путей внутри рабочего каталога RtlDosPathNameToRelativeNtPathName_U может вернуть дескриптор этого каталога и только относительную часть в RTL_RELATIVE_NAME. Если передать дескриптор в OBJECT_ATTRIBUTES.RootDirectory, функция NtCreateFile сможет обратиться непосредственно к процедуре разбора драйвера файловой системы. NTDLL открывает и удерживает этот дескриптор каталога без SHARE_DELETE, поэтому рабочий каталог приложения обычно нельзя удалить.

Абсолютный путь UNC

Пути UNC обращаются к удалённым файловым системам, таким как SMB, WebDAV или общие папки виртуальных машин. Обычно они состоят из двух разделителей, сервера, общего ресурса и необязательного относительного пути к ресурсу. При канонизации общий ресурс считается корнем. Начальные разделители преобразуются в \??\UNC, направляя запрос через Multiple UNC Provider (MUP).

Локальное устройство

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

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

\\localhost\xyz не эквивалентен \\.\xyz: первый путь обращается к общему ресурсу UNC на локальной машине по IP, а второй открывает устройство xyz.

Устаревший DOS также позволяет использовать зарезервированные имена устройств без префикса локального устройства. Например:

К зарезервированным относятся имена PRN, AUX, NUL, CON, LPT[1-9], COM[1-9], CONIN$ и CONOUT$. Последние два не документированы как зарезервированные. Проверка цифры для LPT и COM фактически использует iswdigit и принимает ненулевые надстрочные цифры U+00B2, U+00B3 и U+00B9, позволяя создавать такие имена, как COM².

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

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

Корневое локальное устройство

Последний тип начинается с \\?\ и переходит в диспетчер объектов. В отличие от путей локальных устройств, он пропускает канонизацию: прямые косые черты остаются без изменений, относительные компоненты не сворачиваются, а конечные пробелы и точки сохраняются.

Полный путь канонизируется, а результат NT — нет. Функция RtlDosPathNameToRelativeNtPathName_U особо обрабатывает этот префикс:

Проверка также принимает \??\, хотя RtlDetermineDosPathNameType_U и RtlGetFullPathName_U считают этот синтаксис всего лишь корневым:

Это расхождение легко эксплуатировать, если для проверки и открытия используются разные API.

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

Диспетчер объектов запрещает гораздо меньше символов:

Даже NUL там допустим, поскольку ядро использует строки с явно заданной длиной; обратный слеш должен оставаться зарезервированным как разделитель. Поэтому символы могут находиться в пути, если диспетчер объектов перенаправит его до попадания в NTFS, например через точку монтирования.

В Windows, в отличие от Linux и OS X, канонизация выполняется в пользовательском режиме до того, как ядро откроет путь. Поэтому компоненты с недопустимыми символами могут исчезнуть до любой проверки файловой системы.

В документации исторически утверждалось, что ANSI-версия CreateFile ограничена MAX_PATH и только Unicode-версия может обрабатывать 32 767 символов с префиксом \\?\. На самом деле ANSI-функция тоже работает: она не проверяет длину ANSI до преобразования в Unicode. Предельная длина в 32 767 символов в конечном счёте обусловлена 16-разрядным счётчиком байтов в UNICODE_STRING.

Обход проверок устройств и путей UNC

Наивная проверка UNC может выглядеть так:

Она распознаёт \\?\UNC, но \??\UNC ведёт к тому же назначению, обходя проверку. Даже системная функция PathIsUNC ведёт себя неожиданно:

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

Пути диспетчера объектов через GLOBALROOT обходят даже случай \\?\UNC:

LanManRedirector и WebDavRedirector являются символическими ссылками на \Device\Mup\;NAME. Это позволяет выбирать протокол с помощью пути, похожего на UNC:

Парсер может ошибочно принять evil.com за общий ресурс на сервере с именем ;LanmanRedirector, хотя в действительности это сервер. Explorer, по-видимому, не принимает такую форму, но нативные API вроде CreateFile принимают. Кроме того, она настолько запутывает канонизацию, что становится возможным удалить кажущийся компонентом общего ресурса элемент.

Выводы

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

Пример программы

Следующая программа на C# вызывает рассмотренные выше API. В состав версий Windows начиная с Vista входит компилятор .NET C#, поэтому дополнительный компилятор C не требуется.

Иногда из-за ошибки дескриптор, открытый в привилегированном процессе, попадает в менее привилегированный процесс. Одна такая ошибка в службе Windows Secondary Logon, исправленная в MS16-032, приводила к утечке дескриптора потока с полным доступом. В этой статье объясняется, как с помощью этого дескриптора можно было получить системные привилегии без традиционного повреждения памяти.

Сама ошибка

Служба Secondary Logon существует как минимум со времён Windows XP. Она предоставляет конечную точку RPC, через которую обычные процессы могут создавать процессы с другими маркерами. Общедоступные интерфейсы называются CreateProcessWithTokenW и CreateProcessWithLogonW. Они похожи на CreateProcessAsUser: варианту с маркером требуется SeImpersonatePrivilege вместо SeAssignPrimaryTokenPrivilege, а вариант со входом получает маркер через LsaLogonUser из переданных учётных данных.

Как и CreateProcess, эти API принимают дескрипторы стандартного ввода, вывода и ошибок. Обычно такие дескрипторы попадают к дочернему процессу через наследование. Служба Secondary Logon не является настоящим родителем, поэтому дублирует каждый дескриптор из вызывающего процесса в новый:

Продублированные значения записываются в ProcessParameters структуры PEB целевого процесса, откуда их получает GetStdHandle. Проверка отклоняет значения с установленными двумя младшими битами, если одновременно не установлен бит 29. Настоящие дескрипторы NT кратны четырём.

Ядро особо обрабатывает два отрицательных псевдодескриптора, обычно предоставляемых функциями GetCurrentProcess и GetCurrentThread:

Исключение проверки для бита 29 пропускает псевдодескрипторы. Передача -1 всего лишь дублирует полный доступ к непривилегированному исходному процессу. Однако -2 дублирует полный доступ к текущему RPC-потоку службы Secondary Logon, обычно постоянному рабочему потоку из пула.

CreateProcessWithTokenW недоступна обычному пользователю, поскольку требует SeImpersonatePrivilege. Кажется, что CreateProcessWithLogonW нужны действительные учётные данные, однако режим LOGON_NETCREDENTIALS_ONLY использует их только для удалённых ресурсов, а локальный маркер создаёт на основе вызывающей стороны. Поэтому достаточно любых фиктивных учётных данных:

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

Поскольку утёкший объект принадлежит пулу потоков, он остаётся доступным для последующих запросов RPC. Очевидный подход — SetThreadContext, которая может заменить сохранённые регистры, включая RIP и RSP. У него есть несколько недостатков:

1. Изменяется только состояние пользовательского режима; поток в непрерываемом ожидании может не начать выполнение неопределённо долго.

2. Без дескриптора процесса внедрить шелл-код трудно: вероятно, для обхода DEP потребуется ROP.

3. Даже если данные можно внедрить через крупный запрос RPC, в 64-разрядной системе их адрес может быть неизвестен. GetThreadContext раскрывает часть информации, но её может оказаться недостаточно.

4. Ошибка приводит к аварийному завершению службы.

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

Утёкший дескриптор имеет право THREAD_IMPERSONATE, поэтому атакующий может изменить маркер олицетворения потока службы во время вызова LsaLogonUser. Если очистить маркер, будет использован основной маркер SYSTEM службы, однако если это произойдёт во время более ранней проверки уровня целостности, OpenThreadToken завершится неудачей и доступ будет запрещён.

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

Он получает маркер олицетворения одного потока из другого. Если у исходного потока нет маркера олицетворения, ядро создаёт его из основного маркера исходного процесса. В качестве источника и назначения можно использовать один дескриптор; для потока службы это создаёт маркер олицетворения SYSTEM:

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

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

Разрядность эксплойта должна соответствовать платформе. RPC считает дескрипторы беззнаковыми значениями размером с указатель, поэтому при преобразовании из 32 в 64 бита они дополняются нулями. Следовательно, (DWORD)-2 не равно (DWORD64)-2.

Заключение

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

Пример кода

Код ядра OS X и iOS, загружавший двоичный файл setuid-root, раньше делал старый порт задачи недействительным лишь после помещения новой карты виртуальной памяти в старый объект задачи. Это оставляло короткое окно гонки, в котором атакующий мог изменить память процесса, собиравшегося запуститься с эффективным UID 0. Тот же примитив позволял получить произвольные полномочия, а в OS X — загрузить неподписанное расширение ядра.

Об ошибке сообщили Apple 16 декабря 2015 года; она была исправлена в OS X 10.11.4 и iOS 9.3 как CVE-2016-1757. Исходный отчёт содержит дополнительные технические сведения и обновлённый эксплойт.

Порты задач

В OS X крайне ограниченная реализация ptrace, где нет даже базовых операций чтения и записи памяти. Это один из примеров двойственной природы XNU: рядом с интерфейсом BSD существует параллельная абстракция Mach, поддерживающая отладчики через порты задач.

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

mach_vm_allocate — метод Mach Interface Generator (MIG), реализованный в ядре и объявленный в mach_vm.defs. Первый аргумент указывает целевую задачу. Обладающий правом отправки в порт задачи другого процесса вызывающий может передать этот порт и выделить память в чужом адресном пространстве. Аналогично mach_vm_read и mach_vm_write предоставляют фактический контроль над памятью процесса.

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

execve

Новый порт задачи обычно создаётся для нового процесса через fork или posix_spawn; простое выполнение другого двоичного файла его не сбрасывает. Это создаёт проблему безопасности: как exec может безопасно повысить привилегии setuid-файла, если другой процесс по-прежнему имеет право отправки в старый порт задачи?

Путь выполнения содержит следующую предусмотренную защиту:

Однако execve сложна, и сброс происходит слишком поздно:

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

2. parse_machfile разбирает и загружает образ Mach-O в новую карту и проверяет подпись кода.

3. swap_task_map переключает существующую задачу на новую карту. Теперь вызовы через старый порт работают с адресным пространством нового исполняемого файла.

4. exec_handle_sugid обнаруживает setuid-файл и наконец сбрасывает порт задачи.

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

Создание надёжного эксплойта

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

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

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

Сценарий эксплойта root_shell.sh демонстрирует метод на актуальных на тот момент выпусках OS X. Он использует otool, чтобы получить точку входа setuid-root файла traceroute6.

Идём дальше: подпись кода и полномочия

Во второй фазе parse_machfile одновременно загружает Mach-O и проверяет подпись. В отличие от iOS, OS X обычно не требует подписывать пользовательские исполняемые файлы, но использует подписи для защиты полномочий — подписанных XML-объявлений, встроенных в Mach-O.

Код ядра проверяет полномочия интерфейсами вроде IOTaskHasEntitlement. Загрузчик расширений ядра принимает запросы только от root-процесса с полномочием com.apple.rootless.kext-management.

Это важно, поскольку OS X проверяла подписи kext в пользовательском пространстве. Полномочие отделяло обычный root пользовательского пространства от выполнения кода ядра.

Им обладают два системных файла: kextd и kextload. Эксплойт может сначала выполнить setuid-root файл и получить root, а затем запустить один из этих инструментов и снова выиграть гонку, получив его полномочие.

Изменение kextload

kextload — более простая цель, поскольку может загружать расширение ядра без передачи работы kextd. Эксплойт изменяет checkAccess, заставляя программу считать kextd недоступным и загружать расширение самостоятельно. Затем вызовы checkKextSignature и checkSignaturesOfDependents изменяются так, чтобы сообщать об успехе. После этого kextload принимает подписанные и неподписанные расширения.

Опубликованный эксплойт содержит двоичный патч проверок подписи для OS X 10.11.3, простое расширение Hello World и сценарии load_kext.sh и unload_kext.sh. Всё можно запускать от обычного пользователя; отладочный вывод ядра появляется в Console.app.

Adobe внесла несколько изменений в кучу Flash Player, чтобы усложнить эксплуатацию уязвимостей, особенно обращений к освобождённой памяти. В этой статье их влияние рассматривается на примере эксплойта, объединяющего две ошибки, обнаруженные после внедрения Isolated Heap.

Isolated Heap

Куча MMgc во Flash использует сборку мусора, но также поддерживает неуправляемые выделения фиксированного размера. Исторически эксплойты опирались на её свойства выделения памяти, особенно для Vector, чтобы превратить повреждение кучи в доступ на чтение и запись по всей памяти Flash. ByteArray и BitmapData также встречались в реальных эксплойтах.

Изначально MMgc распределяла память по корзинам на основании типа и размера. Память без сборки мусора использует Fixed allocator, а память со сборкой мусора — GC allocator. Последний имеет около восьми подтипов, определяемых наличием указателей, пользовательских финализаторов и процедур GC. Затем запросы разделяются по размеру, причём крупные объекты получают отдельные страницы.

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

Существует три раздела:

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

2. Данные без указателей, главным образом массивы примитивных значений.

3. Небольшой набор буферных объектов переменного размера, исторически использовавшихся в эксплойтах.

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

CVE-2016-0998

CVE-2016-0998, обнаруженная Mateusz Jurczyk и Natalie Silvanovich, была заявлена 3 февраля 2016 года и исправлена 10 марта. Это неинициализированная переменная, появившаяся при исправлении обращения к освобождённой памяти в ActionScript 2. За предшествующий год было исправлено около 80 похожих ошибок, причём два из этих исправлений внесли неинициализированные переменные.

Полный пример для воспроизведения:

unwatch пытается преобразовать первый аргумент в строку до входа в участок, где вредоносный toString способен освободить объект. При этом наличие аргумента не проверяется:

Во Flash alloca(0) всё равно резервирует минимальные 16 байт, однако цикл инициализации не выполняется. Поэтому args[0] содержит устаревшие данные стека. Уязвимый путь выполняется только тогда, когда младшие биты значения указывают на ScriptObject, то есть оканчиваются на 6. При пустом списке аргументов функция быстро завершается, поэтому с устаревшим значением работает только call_toString. Она ищет toString среди членов предполагаемого объекта и выполняет виртуальные вызовы.

Из этого следуют три стратегии эксплуатации:

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

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

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

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

Третий вариант предоставляет широкое окно для замены, однако та должна совпадать по разделу, типу аллокатора и размеру. Этим условиям соответствуют лишь около десяти кандидатов, и все они происходят от класса ActionScript 3 ScriptObject. Первый виртуальный вызов соответствует ScriptObject::getDescendants, которая немедленно создаёт исключение AS3. Поскольку обработчики исключений в этом контексте не инициализированы, результатом становится аварийное завершение из-за нулевого указателя. Подходящего объекта для замены найти не удалось.

Таким образом, казалось, что для ошибки нужна отдельная утечка информации.

CVE-2016-0984

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

Уязвимый метод загружает данные PCM из массива ActionScript, обрабатывает их и сохраняет в объекте Sound:

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

Утечка таблицы виртуальных функций

Большинство объектов в разделе 2 — массивы примитивов. Там же находятся типизированные массивы указателей, но обычно они указывают на примитивные данные, по которым нельзя с пользой перемещаться через эту ошибку только для чтения. Управляемый сценарием массив виртуальных объектов найти не удалось.

Однако LIR JIT-компилятора ActionScript реализует небольшой аллокатор, страницы которого выделяются как крупные массивы символов в разделе 2. Эти страницы переменного размера часто содержат объекты с таблицами виртуальных функций. Выбрав размер PCM, совпадающий с часто встречающимся выделением страницы LIR, удалось прочитать таблицу виртуальных функций и обойти ASLR.

Поиск управляемого буфера

LocaleID.determinePreferredLocales выделяет массив значений char*, полученных из переданного вектора строк. Эти указатели можно прочитать через освобождённое выделение PCM. Строки ActionScript неизменяемы и заканчиваются на NUL, поэтому в 64-разрядных системах могут содержать только один указатель. Вместо этого внутренние массивы символов, созданные данным API, освобождались и заменялись целочисленными массивами. В отличие от обычных строк сценария, эти внутренние массивы относятся к разделу 2, а не 3.

BitmapData.paletteMap принимает четыре целочисленных массива по 256 элементов и копирует их в выделение из 1024 элементов. К этому моменту известны адреса и таблицы виртуальных функций, и буфера, поэтому неизменяемость не мешает. Обычно временные массивы освобождаются при возврате, однако поздний входной элемент может определить valueOf, создающий исключение. Большая часть данных копируется до того, как исключение прервёт путь очистки, оставив управляемое выделение в живых. Этот приём с исключением полезен во многих методах.

Теперь у эксплойта есть и указатель на код, и управляемый буфер — этого достаточно для использования CVE-2016-0998.

Собираем всё вместе

CVE-2016-0998 требует оставить в нативном стеке указатель на управляемый буфер с тремя младшими битами, равными 6. Преобразование UTF-8 в UTF-16 использует стек, когда итоговая строка UTF-16 короче 256 байт, поэтому тщательно подобранное содержимое строки позволяет поместить туда указатель.

Сначала эксплойт увеличивает нативный стек C++, чтобы устаревшие значения не вызывали преждевременных сбоев. Рекурсия в ActionScript увеличивает другой стек, поэтому эксплойт заставляет swapDepths рекурсивно вызывать toString в нативном коде:

Возвращаемое значение преобразуется из UTF-8 в UTF-16 и помещается в нативный стек. Преобразование выполняется только для строки, статически закодированной в SWF, но не для строки, созданной при выполнении ActionScript, поэтому эксплойт динамически строит второй SWF.

На первом этапе soundPCM.swf использует CVE-2016-0984, чтобы получить таблицу виртуальных функций и выделить управляемый буфер. JavaScript передаёт его адрес в test.cgi, чей код Python вставляет адрес в статическую строку в new.swf. Пользовательский кодировщик UTF-8 всегда создаёт трёхбайтовые последовательности, сохраняя смещения SWF неизменными независимо от значения указателя. Преобразование останавливается на старших байтах 0x0000 64-разрядного указателя, ограничивая приём одним указателем, но этого достаточно.

Созданный SWF загружается один раз с num=15 для подготовки стека и ещё раз с num=14 для активации unwatch, вызывающей нативную обработку toString для поддельного объекта.

Что находится в буфере

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

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

Заключение

Isolated Heap значительно усложнила и замедлила эксплуатацию CVE-2016-0998, вынудив применить отдельную утечку информации, которая прежде, вероятно, не потребовалась бы. Слабые места сохранились, особенно выделения JIT и массивы указателей в общем разделе данных. Тем не менее изоляция кучи стала существенным улучшением, и Project Zero работала с Adobe над дальнейшим усилением защиты.

1 июня 2016 года Project Zero сообщила об ошибке произвольной рекурсии в ядре Linux. Локальный пользователь Ubuntu мог активировать её в системе, установленной с поддержкой шифрования домашних каталогов. Отчёт об ошибке содержит пример аварийного завершения и полный эксплойт.

Предварительные условия

Процессы пользователя в Linux обычно имеют стек размером 8 Мбайт с защитной страницей под ним, поэтому бесконечная рекурсия в норме приводит к контролируемой ошибке. Стеки ядра намного меньше: 4096 или 8192 байта на 32-разрядной x86 и 16 384 байта на x86-64 в зависимости от THREAD_SIZE_ORDER и THREAD_SIZE. Они выделяются buddy allocator и исторически не имели защитных страниц. Поэтому переполнение сталкивалось с обычными данными ядра, делая строгие ограничения выделений в стеке и рекурсии жизненно необходимыми.

Большинство файловых систем Linux являются псевдофайловыми системами или используют блочное устройство. ecryptfs и overlayfs — многослойные файловые системы: они используют каталоги нижележащих файловых систем и преобразуют обращения. Overlayfs объединяет несколько деревьев, а ecryptfs прозрачно шифрует данные.

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

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

• mem охватывает полный диапазон виртуальных адресов и требует PTRACE_MODE_ATTACH.

• environ охватывает диапазон от mm->env_start до mm->env_end и требует PTRACE_MODE_READ.

• cmdline обычно охватывает диапазон от mm->arg_start до mm->arg_end при условии, что последний байт равен NUL.

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

Для них намеренно предоставлены только операции чтения и записи, но не mmap:

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

Уязвимость

Создадим процесс A, а затем смонтируем ecryptfs в /tmp/$A, используя /proc/$A как нижележащий каталог. При одном ключе ecryptfs шифрование имён файлов отключено. /tmp/$A/environ и /tmp/$A/cmdline можно отобразить в память, если их аналоги procfs начинаются с допустимого заголовка ecryptfs.

/proc/$A/mem менее полезен: непривилегированный процесс не может отобразить нулевой адрес, поэтому чтение по смещению ноль всегда возвращает -EIO и там нельзя разместить необходимый заголовок.

В ядрах Ubuntu включён CONFIG_CHECKPOINT_RESTORE, позволяющий непривилегированному процессу задать arg_start, arg_end, env_start и env_end с помощью:

Так environ и cmdline направляются на произвольные пользовательские отображения. Ядра без checkpoint/restore всё ещё можно атаковать, повторно запуская процесс с выбранными размерами аргументов и окружения и заменяя часть отображения стека.

Загрузим допустимый зашифрованный файл ecryptfs в процесс A и направим диапазон его окружения на эти данные. Теперь /tmp/$A/environ предоставляет расшифрованное представление, которое процесс B может отобразить. Многократное шифрование данных создаёт «матрёшку» ecryptfs, позволяя цепочке процессов отображать диапазоны окружения друг друга:

Если страницы отсутствуют, ошибка в C заставляет ecryptfs читать /proc/$B/environ, вызывая ошибку в B, который читает /proc/$A/environ и вызывает ошибку в A. Произвольное удлинение цепочки переполняет стек ядра. Повторяющийся участок выглядит так:

Для атаки требуется разрешение смонтировать ecryptfs поверх /proc/$pid. Установка ecryptfs-utils, которую Ubuntu выполняла для зашифрованных домашних каталогов, предоставляла setuid-помощник /sbin/mount.ecryptfs_private. Он требовал владения исходным каталогом, но пользователи «владеют» каталогами procfs собственных процессов.

Эксплуатация ошибки

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

В старых переполнениях стека ядра можно было перезаписать restart_block или addr_limit в thread_info, как описано в infiltrate12-thestackisback.pdf (файл в files/infiltrate12-thestackisback.pdf). Это позволяло непосредственно выполнять пользовательский код либо читать и записывать память ядра через copy_from_user() и copy_to_user().

Здесь restart_block уже был перемещён в другое место. Рекурсивный стек содержал кадры kernel_read(), поэтому addr_limit имел значение KERNEL_DS и вернулся бы к USER_DS при раскрутке. В Ubuntu Xenial также был включён CONFIG_SCHED_STACK_END_CHECK, размещавший над thread_info проверяемую планировщиком канарейку.

Вместо повреждения thread_info эксплойт переполняет стек в непосредственно предшествующее ему выделение buddy allocator, заставляя это выделение перекрыться с активными кадрами стека. Канарейка и несколько полей должны остаться неповреждёнными:

В некоторых кадрах рекурсии есть пробелы. Использование cmdline внизу создаёт область из пяти QWORD, не затрагиваемую при спуске, которой достаточно, чтобы охватить участок от STACK_END_MAGIC до flags. Отладочный модуль, предварительно заполнявший стек маркерами, сделал эти пробелы видимыми:

Пробел появляется только на определённых глубинах. Точно выровнять его позволяют три средства управления:

1. Каждый уровень рекурсии может использовать environ или cmdline, у которых различаются размеры кадров и пробелы.

2. Любой copy_from_user() может инициировать последнюю страничную ошибку.

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

Итоговая цепочка сочетала environ и cmdline, входила через write() и использовала обработчик записи VFS uid_map.

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

Предшествующее выделение заполняется страницами каналов из buddy allocator. Пока процесс-жертва создаётся через clone() для сокращения шума выделений, эксплойт распыляет новые пустые каналы. Их страницы заполняются лишь до первого сохранённого RIP после ожидаемого RSP, остановленного в FUSE; дальнейшая запись повредила бы данные, используемые до перехвата управления. Когда жертва блокируется в FUSE, вторая запись в каждый канал заменяет сохранённый RIP и последующий стек управляемыми атакующим значениями.

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

ROP могла бы напрямую вызвать commit_creds(prepare_kernel_cred(NULL)). Выбранный подход сохраняет существующее значение KERNEL_DS в addr_limit и возвращается прямо в пользовательский режим, не раскручивая кадры, которые восстановили бы USER_DS:

Завершение сервера FUSE возобновляет выполнение в post_corruption_user_code. Поскольку проверки адресов copy_to_user() отключены, канал предоставляет произвольную запись в ядро:

Теперь возможны произвольные чтение и запись пользовательского пространства. Чтобы получить оболочку root, эксплойт перезаписывает статический обработчик дампа ядра и создаёт SIGSEGV:

Исправление ошибки

Путь закрыли двумя исправлениями. 2f36db710093 запрещает ecryptfs открывать нижележащие файлы без обработчика mmap. e54ad7f1ee26 дополнительно запрещает накладывать её на procfs.

Полный эксплойт для получения root продемонстрировал, что переполнения стека ядра могут возникать из-за неочевидной рекурсии и оставаться пригодными для эксплуатации вопреки современным мерам защиты. В отчёте рекомендовалось добавить защитные страницы и перенести thread_info от нижней границы стека. Andy Lutomirski уже начал эту работу и впоследствии опубликовал исправления с защитными страницами.

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

Предыстория

Шрифты представляют значительную поверхность атаки. Их форматы сложны структурно и семантически, большинство растеризаторов берёт начало в ранних 1990-х годах и написано на C или C++, а управляемые атакующим файлы поступают через документы, веб-страницы, файлы очереди печати и другие удалённые каналы. TrueType и OpenType также содержат мощные виртуальные машины для описания контуров глифов. Их арифметические и побитовые операции и средства работы с памятью позволяли создавать надёжные цепочки эксплуатации.

Ошибки в шрифтах неоднократно встречались в реальных атаках: Duqu использовал 0-day в TTF для ядра Windows, comex эксплуатировал ошибку Type 1 во FreeType для джейлбрейка iOS, а уязвимости шрифтов присутствовали в работах Joshua Drake и Keen Team на Pwn2Own. Только Microsoft за предшествующее десятилетие выпустила десятки бюллетеней безопасности для шрифтовых движков. Когда широко развёрнутое программное обеспечение настолько хрупко, что исследователи легко получают удобные 0-day, отдельные исправления ошибок не решают более общую проблему.

Улучшение состояния безопасности программного обеспечения для шрифтов

Зрелые реализации вряд ли могли исчезнуть, отчасти из-за важности производительности растеризации. Общая защита состоит в сокращении привилегий обработки шрифтов, например запуске FreeType в песочнице или переносе разбора шрифтов Windows из ядра, что начала делать Windows 10. Project Zero могла вместо этого повысить стоимость поиска уязвимостей, удалив легко доступные для фаззинга ошибки.

С 2012 года внутренняя инфраструктура Google масштабно фаззила FreeType, что принесло более 50 отчётов, многие из которых были связаны с эксплуатируемым повреждением памяти. Открытый исходный код делал работу с FreeType сравнительно простой: исследователи могли проверять код, применять статический анализ и компилировать его с AddressSanitizer, MemorySanitizer и SanitizerCoverage для недорогого обнаружения ошибок и фаззинга с обратной связью по покрытию.

Реализация шрифтов Windows была сложнее. Исходный код отсутствовал; общедоступные символы охватывали обработку растровых шрифтов и TTF в win32k.sys, но не Type 1 и OTF в ATMFD.DLL. Для ручного анализа требовалась обратная разработка, а движок работал в ядре внутри модуля, общего с графической подсистемой. Special Pools улучшали обнаружение, тогда как универсальная обработка исключений могла скрывать сбои.

В начале 2015 года ручной аудит виртуальной машины CharString для Type 1/CFF в ATMFD выявил восемь уязвимостей ядра. Этот компонент был автономным и обозримым, но полная кодовая база шрифтов и пространство её состояний были слишком велики для того же подхода. Фаззинг давал меньше уверенности в покрытии, зато гораздо лучше масштабировался и исторически, по-видимому, отвечал более чем за 90% ошибок в шрифтах.

Кампания против ядра Windows началась в мае 2015 года. Примерно через год и несколько циклов исправлений протестированное ядро оказалось чистым для использованных методов.

Результаты

Записи tracker содержали краткие описания сбоев, журналы Special Pool для Windows 7 x86 и шрифты для доказательства концепции. Для некоторых сбоев также требовался специальный загрузчик шрифтов, переданный Microsoft в закрытом порядке и описанный во второй части.

Отчёты поступили тремя пакетами. В первом было большинство ошибок, поскольку фаззер сразу достиг множества новых путей. Более поздние и длительные запуски выявили сбои, ранее скрытые более частыми bugcheck. Microsoft исправила каждый пакет в пределах 90-дневного срока Project Zero. Для проблемы 684 потребовалось дополнить отчёт после того, как стороны определили конфигурацию системы, необходимую для воспроизведения.

Ошибки охватывали обработку TTF и OTF в нескольких таблицах SFNT. Большинство позволяло локально повышать привилегии, в том числе выходить из песочницы, и потенциально удалённо выполнять код в приложениях, непосредственно передающих недоверенные файлы в GDI. Почти все они сохранялись в версиях Windows новее тестовой Windows 7. Растеризация в пользовательском режиме Windows 10 снижала последствия для повышения привилегий, но выполнение кода внутри ограниченного процесса всё ещё было возможно.

Совпадения

Весомое подтверждение ценности защитного исследования уязвимостей — совпадение с боевыми эксплойтами, особенно с 0-day, применяемыми против пользователей. Первые две зарегистрированные проблемы, 368 и 369, вскоре оказались идентичны ошибке TTF, использованной Keen Team на Pwn2Own 2015, и ошибке OTF, найденной вместе с готовым эксплойтом в утечке Hacking Team.

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

Совпадение с 0-day Hacking Team

Первый пакет из семи сбоев OpenType и четырёх TrueType планировалось исправить во вторник обновлений августа 2015 года. 20 июля Microsoft неожиданно выпустила внеплановый бюллетень MS15-078:

Mateusz Jurczyk значился среди упомянутых в нём исследователей:

Проблема 369 совпала с боевым эксплойтом, независимо найденным двумя исследователями в данных Hacking Team, утёкших 5 июля 2015 года. Утечка включала исходный код продукта для слежки, деловые документы и 0-day для Flash Player, ядра Windows, Internet Explorer, SELinux и других целей. До 20 июля CVE-2015-2426 не была известна публично, что указывает на закрытое сообщение Microsoft.

Эксплойт повышал привилегии в Windows 8.1. Первопричиной было ошибочное предположение в драйвере OpenType ATMFD:

Class1Count — 16-разрядное поле GPOS. Код предполагал, что оно ненулевое, и безусловно копировал первый 32-байтовый элемент. При нулевом значении выделялось лишь восемь байт, а буфер пула переполнялся на 32 байта. Подготовка пула размещала непосредственно следом объект из win32k.sys типа CHwndTargetProp, позволяя перезаписать его таблицу виртуальных функций адресом пользовательского режима. После утечки базового адреса win32k.sys ROP-цепочка отключала SMEP и запускала шелл-код повышения привилегий.

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

Совпадение с Pwn2Own

11 августа появились исправления для остальной части первого пакета. Microsoft снова указала другую группу в благодарностях за одну из находок:

CVE-2015-2455, отслеживаемая как ZDI-15-388 и проблема 368, была связана с инструкцией TrueType IUP. Keen Team использовала её для выхода из песочницы и полной компрометации системы на Pwn2Own 2015.

В спецификации TrueType явно сказано, что применение IUP к зоне 0 является ошибкой:

Обработчик win32k!itrp_IUP не проверял, что текущая зона отличается от зоны 0. Он обрабатывал зону 0 как зону 1, вызывая переполнение буфера пула с содержимым и длиной, в значительной степени подконтрольными атакующему. Для активации требовались три инструкции:

Инверсия одного бита могла изменить аргумент SZP2 или SZPS с 1 на 0. Поэтому это был самый частый сбой первого запуска простого фаззера. Позднее генератор программ TrueType создавал его примерно в каждом втором случае, из-за чего до выпуска исправления Microsoft пришлось запретить генератору такую конструкцию.

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

Заключительные мысли

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

Незадолго до этой публикации была открыта проблема 785 с подробностями повреждения пула в ATMFD.DLL на поверхности атаки NamedEscape, где также находилась вторая 0-day Hacking Team для ядра Windows — CVE-2015-2387.

Symantec Endpoint Protection был известным продуктом корпоративной безопасности. Symantec повторно использовала его основной движок во всём ассортименте, включая потребительские продукты Norton. Project Zero обнаружила в этом движке несколько критических уязвимостей, многие из которых допускали удалённую эксплуатацию и создание червей.

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

Были затронуты следующие продукты:

• Norton Security, Norton 360 и устаревшие продукты Norton на всех платформах.

• Все версии Symantec Endpoint Protection на всех платформах.

• Symantec Email Security и Symantec Protection Engine.

• Symantec Protection for SharePoint Servers.

• Другие продукты, использующие тот же движок.

Некоторые продукты не могли обновляться автоматически, поэтому администраторам требовалось принять непосредственные меры.

Распаковщики в ядре: возможно, не лучшая идея?

Упаковщики исполняемых файлов, например UPX, сжимают бинарные файлы и изменяют их вид на диске. Антивирусные движки обрабатывают их с помощью специализированных распаковщиков распространённых форматов и эмуляции нестандартных форматов. Оба подхода сложны, и реализовать их безопасно непросто. Песочница и жизненный цикл безопасной разработки помогают, однако распаковщики и эмуляторы неоднократно порождали уязвимости в продуктах Comodo, ESET, Kaspersky, FireEye и других компаний.

Symantec добавила ещё одну опасность: её распаковщики работали в ядре Windows.

CVE-2016-2208

ASPack — давно существующий коммерческий упаковщик исполняемых файлов. Symantec включала распаковщики старых версий ASPack. В одном из них секция PE со значением SizeOfRawData, превышающим SizeOfImage, вызывала элементарное переполнение: код выделял SizeOfImage байтов, но копировал все доступные данные секции.

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

Затем тест NASM использовал противоречивые значения секции PE:

Полный исходный код приложен к проблеме 820.

В Linux, macOS и других Unix-подобных платформах ошибка приводила к переполнению кучи антивирусного процесса с правами root. В Windows она повреждала память ядра. Фильтр-драйвер Symantec перехватывал системный ввод-вывод, поэтому для запуска сканирования было достаточно отправить файл по электронной почте или разместить ссылку на него; жертве не требовалось открывать файл. Таким образом, ошибка позволяла создать червя и скомпрометировать весь парк корпоративных компьютеров.

Переполнение буфера стека в потоке PowerPoint

Записи PowerPoint документированы в MS-PPT, но находятся внутри потоков формата Compound File Binary. Библиотека «декомпоновщика» Symantec предоставляла над этими потоками напоминающую stdio абстракцию для извлечения метаданных и макросов.

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

Получившееся переполнение стека происходило в пути, используемом функцией Symantec «BloodHound Heuristics». В Norton та же функция называлась «Advanced Heuristic Protection». Администратор мог выбрать режим Low, Automatic или Aggressive; по умолчанию использовался Automatic, динамически включавший дополнительные проверки.

Простой тест надёжно вызывал сбой в режиме Aggressive, но сначала не срабатывал в режиме по умолчанию. Поиск в корпусе VirusTotal Intelligence показал, что некоторые документы PowerPoint заставляли режим Automatic выбирать агрессивный анализ. Их необычный поток содержал ExOleObjStgCompressedAtom. Извлечение этого сжатого объекта и включение его в тестовый поток с помощью %incbin в NASM воспроизвело переключение.

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

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

Сначала требовалось найти поблизости инструкцию int3:

Управляемая частичная перезапись стабильно попадала на неё:

Затем последовательность гаджетов могла расширить доступный диапазон и свести оставшуюся задачу к обычной проблеме ROP. Исходный код эксплойта приложен к проблеме 823.

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

• Norton Antivirus для macOS и Windows.

• Symantec Endpoint для macOS, Windows, Linux и Unix.

• Symantec Scan Engine на всех платформах.

• Symantec Cloud и NAS Protection Engine.

• Symantec Email Security.

• Продукты защиты Symantec для SharePoint, Exchange, Notes и других систем.

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

Результатом становилось удалённое выполнение кода с правами SYSTEM в Windows и root на других платформах.

Управление уязвимостями

Производители антивирусов, как и все разработчики, обязаны отслеживать выпуски и объявления об уязвимостях вышестоящих проектов и распространять обновления. Декомпоновщик Symantec включал код, производный от открытых проектов, таких как libmspack и unrarsrc, но не получал их обновлений как минимум семь лет. Поэтому в продуктах Symantec сохранялись десятки публично известных уязвимостей, для некоторых из которых существовали общедоступные эксплойты.

Заключение

Помимо приведённых примеров Project Zero обнаружила дополнительные переполнения стека и ошибки повреждения памяти. Команда безопасности Symantec быстро устранила зарегистрированные проблемы.

В первой части были описаны мотивация и результаты годовой кампании по фаззингу шрифтов ядра Windows, включая совпадения с находками Keen Team и Hacking Team. Эта часть посвящена инженерным решениям, сделавшим кампанию эффективной. Многие из них относились к конкретной цели, но лежащие в их основе уроки применимы гораздо шире.

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

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

Подготовка корпуса входных данных

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

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

• Шрифты TrueType (.ttf), обрабатываемые win32k.sys.

• Шрифты OpenType (.otf), обрабатываемые ATMFD.DLL.

• Растровые шрифты (.fon, .fnt), обрабатываемые win32k.sys.

• Шрифты Type 1 (.pfb, .pfm, .mmm), обрабатываемые ATMFD.DLL.

Type 1 исключили, поскольку Windows требует как минимум пару PFB/PFM, его структура сравнительно проста, виртуальная машина CharString уже была тщательно проверена, а значительная часть оставшейся логики ATMFD общая с OpenType. Растровые шрифты также убрали после того, как они дали только одно постоянное необработанное деление на ноль.

Измерять покрытие ядра Windows не планировалось, поэтому обычная дистилляция корпуса была недоступна. Проект повторно использовал избыточный корпус FreeType, сохранив до 100 образцов на каждую пару базовых блоков. После извлечения файлов TTF и OTF получилось 19 507 образцов: 14 848 TrueType и 4659 OpenType общим объёмом около 2,4 Гбайт.

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

Мутация TTF и OTF

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

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

Обозначим вероятность успешной загрузки изменённой таблицы i как p_i:

Успешность всего файла равна произведению этих вероятностей:

Если считать вероятности таблиц равными, получаем:

Для n = 10 значимых таблиц и идеальной вероятности всего файла 0,5:

Таким образом, каждая изменённая таблица в среднем должна успешно разбираться примерно в 93% случаев.

Использовались пять простых алгоритмов:

• Bitflipping: инвертировать от одного до четырёх соседних битов в выбранных байтах.

• Byteflipping: заменить выбранные байты случайными значениями.

• Chunkspew: скопировать данные из одной области входа поверх другой.

• Special Ints: вставить граничные и магические целочисленные значения.

• Add Sub Binary: прибавить случайные целые числа к двоичным значениям или вычесть их.

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

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

В сочетании с небольшим дизассемблером и ассемблером SFNT на C++ это давало «умно-глупую» мутацию: простые случайные операции, но с управляемым средним поведением парсера. Пятнадцать из шестнадцати уязвимостей кампании были получены именно в такой конфигурации.

Генерация программ TTF

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

Виртуальная машина CharString в ATMFD уже была проверена, поэтому специальный генератор написали только для TrueType. Он создавал структурно допустимые инструкции со случайными аргументами и встраивал их в настоящие файлы TTF.

ttx.py из FontTools преобразует шрифты SFNT в редактируемый XML и обратно, включая ассемблирование и дизассемблирование программ TrueType:

Все файлы TTF заранее преобразовывались в TTX, а сценарий Python на xml.etree.ElementTree очищал каждый элемент assembly. Сохранение настоящей геометрии каждого шрифта было лучше одного минимального шаблона, поскольку инструкции зависят от точек, контуров и конфигурации.

Генератор реализовывал каждую инструкцию из спецификации, а также:

1. Подсчитывал контуры и точки глифов, чтобы выбирать допустимые индексы.

2. Отслеживал указатели зон ZP0, ZP1 и ZP2, изменяемые SZP0, SZP1, SZP2 и SZPS.

3. Расширял таблицу CVT до 32 768 случайных элементов.

4. Увеличивал ограничения в maxp, чтобы исходный шрифт не завершал созданные программы преждевременно.

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

Генератор сразу повторно обнаружил ошибку IUP, из-за чего до выхода исправления перед каждой IUP ему пришлось устанавливать ZP2 в 1. Во второй итерации фаззинга он нашёл проблему 507 — уникальное переполнение пула в win32k!or_all_N_wide_rotated_need_last и связанных процедурах отрисовки текста. Одна уникальная серьёзная ошибка и одно совпадение оправдали работу над генератором.

Фаззинг ядра в Bochs

Система должна была масштабироваться на узлах Linux без аппаратной виртуализации. Можно было использовать QEMU, но предшествующая работа над Bochspwn обеспечила знакомство с эмулятором x86 Bochs и его инструментированием. Полная эмуляция достигала лишь около 100 МГц и была в 20–50 раз медленнее нативного выполнения, однако это компенсировали тысячи рабочих процессов.

Мутация и генерация выполнялись вне Windows в инструментировании Bochs. В гостевой системе находился только harness.exe, запускавшийся при загрузке, запрашивавший входные данные и отображавший каждый глиф в нескольких стилях и размерах.

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

EAX содержал код операции, а ECX и EDX — параметры. Были определены три операции:

• REQUEST_DATA(lpBuffer) копировала свежий шрифт в память гостевой системы.

• SEND_STATUS(dwStatus) сообщала, загрузился ли шрифт.

• DBG_PRINT(lpMessage) выводила диагностическую строку.

Первый вызов REQUEST_DATA всегда возвращал исходный шрифт, чтобы harness мог извлечь допустимые описатели LOGFONT. Последующие запросы возвращали мутации:

Мутация выполнялась синхронно и быстро на C++. Созданные программы были медленнее, поскольку Bochs запускал Python и ttx.py, но эти накладные расходы были незначительны рядом с гостевыми тестами, занимавшими от половины секунды до нескольких минут.

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

Клиентский harness

Генерация входных данных бесполезна, если harness не достигает уязвимых путей или использует лишь малую часть файла. Поэтому его устройство значительно превосходило простой запуск Windows Font Viewer или отрисовку печатных символов ASCII одним размером.

AddFontResource сообщала, сколько шрифтов содержит файл. Недокументированная GetFontResourceInfoW с QFR_LOGFONT возвращала LOGFONT для каждого встроенного начертания, что требовало начального пробного запуска с неизменённым файлом на диске.

В настоящих итерациях для установки шрифтов непосредственно из памяти использовалась AddFontMemResourceEx, что было намного быстрее. CreateFontIndirect создавала по пять объектов GDI на каждый LOGFONT: один исходный и четыре со слегка случайными настройками высоты, ширины, курсива, подчёркивания и зачёркивания. Постоянное случайное начальное число обеспечивало воспроизводимость запусков.

GetFontUnicodeRanges перечисляла поддерживаемые символы. Harness вызывал DrawText для каждой группы из десяти символов, GetKerningPairs один раз для каждого начертания и GetGlyphOutline с разными аргументами для каждого глифа. В конечном итоге 16 сбоев возникли через четыре системных вызова: NtGdiGetTextExtentExW, NtGdiAddFontResourceW, NtGdiGetCharABCWidthsW и NtGdiGetFontUnicodeRanges.

Оптимизация системы и обнаружение bugcheck

Каждый эмулированный цикл имел значение. Гостевая Windows 7 была облегчена следующим образом:

• выбрана классическая тема и визуальная настройка «наилучшее быстродействие»;

• отключены необязательные службы, автозагрузка, индексирование, подкачка и гибернация;

• включена загрузка Minimal/Safe Mode с VGA;

• удалены стандартные компоненты и ненужные файлы Windows;

• explorer.exe заменён на harness в качестве оболочки.

Размер образа диска уменьшился примерно до 7 Гбайт, а загрузка в Bochs занимала менее пяти минут. Для подготовки образов с более поздними уровнями исправлений приходилось временно отменять многие изменения.

Одна оптимизация выявила проблему 684, возникавшую только при отключённой настройке «Сглаживать неровности экранных шрифтов». Сначала Microsoft не могла воспроизвести ошибку; после определения этой настройки Project Zero сбросила дату отчёта, и Microsoft исправила проблему в новом 90-дневном окне.

Windows была настроена на автоматическую перезагрузку после bugcheck:

Bochs обнаруживал сброс с помощью:

Поскольку harness работал бесконечно, а почти всё остальное программное обеспечение было отключено, сброс являлся надёжным сигналом сбоя. Метод терял регистры, трассировки стека и дампы, однако Special Pools и идентичный образ воспроизведения делали сохранённого шрифта достаточно почти для каждого сбоя. Более сложные альтернативы могли перехватывать исключения или запись на диск либо захватывать синий экран.

Воспроизведение сбоев

Виртуальная машина VirtualBox повторяла среду фаззинга. Её harness читал шрифт с диска вместо использования LFENCE. Затем контроллер:

1. Читал последний образец из progress.txt.

2. Копировал новый минидамп в общую папку под именем образца.

3. Запускал в WinDbg !analyze -v и сохранял рядом текстовый отчёт.

4. Удалял локальный дамп.

5. Выбирал и записывал следующие входные данные.

6. Несколько раз запускал harness.

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

8. Если сбоя не происходило, перезагружал систему через ExitWindowsEx, чтобы загрязнённое состояние не попало в следующий образец.

Каждый выходной каталог содержал и двоичный дамп, и текстовый отчёт с возможностью поиска. Полная перезагрузка гарантировала принадлежность результата одному шрифту. Оптимизированная загрузка занимала менее 50 секунд, а тестирование обычно менее 10 секунд, что давало около 1500 образцов в день. 64-разрядная виртуальная машина воспроизведения не принесла практической пользы, поскольку ошибки обычно воспроизводились либо на обеих архитектурах, либо ни на одной.

Минимизация образцов

Мутации SFNT сначала минимизировались по таблицам и иногда по байтам. Инструмент уровня таблиц сравнивал исходные и изменённые файлы, восстанавливал выбранные таблицы и повторял тест. Если после восстановления таблицы сбой сохранялся, она была несущественной; повторные испытания сокращали входные данные до одной–трёх необходимых таблиц и помогали устранять дубликаты по трассировкам стека.

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

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

Дальнейшая работа Фаззинг с обратной связью по покрытию

В кампании не использовалась обратная связь по покрытию. AFL, libFuzzer и похожие системы могут улучшать результаты на порядок, но инструментирование Bochs внесло бы большие накладные расходы и должно было бы отличать инструкции обработки входных данных от посторонней активности ядра. Более широкий проект покрытия ядра Windows, вероятно, использовал бы аппаратную виртуализацию и Virtual Machine Introspection, по духу аналогично Linux syzkaller.

Улучшенные мутации

Среди возможных улучшений — дополнительные мутаторы, объединение и склейка, коэффициенты для отдельных шрифтов вместо всего корпуса, генератор CharString OpenType, безопасные способы фаззинга хрупких таблиц вроде cmap, head, hhea, name и loca, а также мутация TTX вместо скомпилированных двоичных данных.

Другие версии Windows

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

Улучшенное обнаружение сбоев в Bochs

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

Итоги

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

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

В этой статье объясняется, как теневые каталоги позволяют внедрять файлы и проводить атаки проверки и использования из песочницы, демонстрируется CVE-2016-3219 и описывается исправление Microsoft MS16-092.

Теневые каталоги объектов

Диспетчер объектов получил новый системный вызов создания каталога NtCreateDirectoryObjectEx. По сравнению с NtCreateDirectoryObject он принимает дескриптор другого каталога и флаги:

Точка останова ядра выявила вызывающую сторону:

Теневой дескриптор ссылался на обычный каталог именованных объектов сеанса:

Новым каталогом было пространство имён, относящееся к AppContainer:

AppContainer сначала ищет в своём закрытом каталоге, а затем переходит к BaseNamedObjects, чтобы обычные и изолированные приложения могли совместно использовать глобальные ресурсы. Каталоги устройств DOS отдельных пользователей применяют похожую схему, рассмотренную в статье «Драйверы Windows действительно коварны».

Вспомогательная функция поиска ядра явно показывает эту связь:

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

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

У примитива есть ограничения. Привилегированная цель должна открыть путь диспетчера объектов, хотя сторона, управляющая полным путём, часто может использовать префикс \\?\. Как и точки подключения NTFS, эта техника изменяет поиск конечного ресурса, а не позволяет свободно заменить его имя.

Двойная проблема

CVE-2016-3219 затрагивала меру защиты Custom Font Disable в Windows 10. Эта политика должна была не допустить передачи недоверенных шрифтов парсерам ядра — поверхности атаки, исследованной в серии BLEND.

Соответствующая логика win32k фактически выглядела так:

Драйвер открывает предоставленный пользователем путь, подтверждает по полученному имени файлового объекта, что тот находится в \Windows\Fonts, закрывает его, а затем снова открывает исходный путь для разбора. Это прямая гонка TOCTOU.

Теневой поиск делает гонку детерминированной. Предположим, атакующий может записывать данные в C:\ABC. Два вложенных созданных атакующим каталога объектов используют \Device как тень. Сначала локальная запись HarddiskVolume1 заставляет путь разрешаться в настоящий системный шрифт:

win32k проходит по каталогам объектов до ABC. Когда HarddiskVolume1 там отсутствует, поиск переходит к тени \Device, находит настоящее устройство тома и просит NTFS открыть \Windows\Fonts\somefont.ttf. После того как NTFS открывает его, прежний путь диспетчера объектов больше не виден; запрос имени файла показывает только законный путь системного шрифта.

Оппортунистическая блокировка системного шрифта сообщает, когда win32k начинает первое открытие. В этот момент драйвер файловой системы уже зафиксировал выбор файла, поэтому атакующий удаляет локальный каталог HarddiskVolume1 внутри промежуточного каталога SWITCH:

При втором открытии поиск достигает SWITCH, больше не находит локальный каталог тома и переходит к его тени. В результате NTFS получает запрос \ABC\HarddiskVolume1\Windows\Fonts\somefont.ttf, вся цепочка каталогов которого контролируется атакующим. Имена без двоеточия важны, поскольку имя потока NTFS не может содержать обратные косые черты.

Таким образом, ядро проверяет настоящий системный шрифт, но разбирает управляемый атакующим, обходя Custom Font Disable.

Изменения поведения

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

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

Фаззинг устройств Android выявил CVE-2016-3861, исправленную в бюллетене безопасности Android за сентябрь 2016 года. Уязвимый код пользовательского пространства был доступен через множество поверхностей атаки и позволял как удалённо выполнять код, так и локально повышать привилегии до привилегированного домена SELinux system_server.

Ошибка

Две функции в libutils/Unicode.cpp должны работать согласованно. utf16_to_utf8_length вычисляет размер выходного буфера, после чего utf16_to_utf8 выполняет преобразование. Различие в обработке недопустимых пар суррогатов нарушает этот контракт:

Рассмотрим следующую последовательность байтов UTF-16:

Функция вычисления длины видит две недопустимые пары и прогнозирует нулевой размер выходных данных:

Преобразователь видит недопустимую пару, за которой следует допустимая пара суррогатов, создающая четыре байта UTF-8:

Смешивая обычные допустимые данные UTF-16 с этой последовательностью, атакующий управляет как размером выделения, так и длиной переполнения. Избыток должен быть кратен четырём, а записываемые данные обязаны образовывать допустимый UTF-8; позднее это ограничение усложнит повреждение указателей.

Векторы атаки

Первоначальная цель фаззинга зависела от производителя оборудования, но ошибка находилась в общем коде Android. Одним из перспективных локальных путей был Parcel.cpp: сгенерированные заглушки Binder почти для каждой системной службы вызывают его преобразование строк во входящих посылках. Это позволяет повысить привилегии из untrusted_app до выбранной службы Binder, в том числе до множества служб, размещённых в system_server.

Для универсального удалённого вектора больше подходил mediaserver. Libstagefright преобразует Unicode при разборе тегов ID3:

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

Тестовый файл и эксплойт были приложены к проблеме 840.

Преодоление защитных мер

Предыдущий эксплойт Stagefright намеренно ограничивался правдоподобным доказательством возможности эксплуатации. Новые выпуски Android закрыли некоторые короткие пути, а публичные работы, например Metaphor от NorthBit, повысили надёжность. В этом эксплойте цель исследуется повторно с более мощными примитивами.

Подготовка кучи здесь подробно не воспроизводится; она описана в предыдущей статье и приложенном эксплойте. Первая задача — ASLR. NorthBit повреждала возвращаемые браузеру метаданные, чтобы читать память процесса. Из-за проверок целочисленного переполнения UBSan в Android использовать поле продолжительности стало непрактично: арифметическое переполнение аварийно завершает mediaserver, а не просто усекает утёкшее значение. Ширина и высота видео имеют размер указателя и хранятся непосредственно в выделении метаданных, поэтому они служат более подходящими каналами.

Этап 1: утечка указателя кучи

Переполняемое выделение подготавливается непосредственно перед SharedBuffer, лежащим в основе KeyedVector в объекте MetaData дорожки:

Фрагменты hvcC, применявшиеся в предыдущем эксплойте, хранят внутри MetaData указатель на управляемые атакующим данные. Повреждение нижележащего вектора сдвигает запись высоты на одну строку, и Chrome получает этот указатель как высоту видео:

JavaScript читает значение и повторяет попытки, пока байты указателя не удастся представить допустимым переполнением UTF-8. Этот указатель становится безопасным доступным для записи хранилищем на следующем этапе.

Этап 2: утечка указателя модуля

Затем эксплойт раскрывает адрес исполняемого кода, для чего дважды запускает уязвимость в одном MP4. Вместо перезаписи содержимого SharedBuffer первое переполнение повреждает его метаданные и увеличивает ёмкость так, чтобы она перекрыла следующее выделение. Когда последующие метаданные дорожки увеличивают KeyedVector, SharedBuffer ошибочно считает, что уже имеет достаточно места, и записывает данные в соседний объект.

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

Основная таблица виртуальных функций объекта не нужна, пока он никогда не уничтожается. Унаследованный указатель mWeakRefs должен пережить уменьшение счётчика и не достигнуть нуля; для него повторно используется допустимый доступный для записи указатель кучи из первого этапа. Дальше внутри объекта находится нужный указатель таблицы виртуальных функций в libmedia.so.

Количество записей KeyedVector хранится отдельно, поэтому эксплойт выполняет второе переполнение и несколько управляемых операций с метаданными, расширяя видимый вектор до целевого указателя:

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

Этапы 3–6

К этому моменту атакующий знает адрес управляемых данных и базовый адрес богатой гаджетами libmedia.so. Та же общая техника, что и в предыдущем эксплойте, обеспечивает ROP в mediaserver. В Android M libmedia.so импортирует mprotect, поэтому с помощью ROP можно сделать шелл-код исполняемым. В приложении к отчёту была реализована надёжная и быстрая эксплуатация нескольких версий Android для Nexus 5X. Создание этапов MP4 непосредственно в JavaScript могло бы устранить повторные сетевые запросы.

В BnOMX::onTransact есть полезная ссылка на mprotect, по всей видимости предназначенная для связанной с безопасностью работы с памятью.

Заключительные мысли

Android N существенно усложнила цепочку. Разбор был перенесён из mediaserver в новый, более ограниченный процесс mediaextractor без execmem, что устранило прямой путь через mprotect. Получить первоначальный контроль по-прежнему было возможно, но повышение привилегий пришлось бы выполнять с помощью ROP.

Самоизменяющаяся цепочка ROP могла бы совершать виртуальные вызовы C++ к другим службам, однако SELinux позволяла mediaextractor выполнять вызовы Binder, но не искать службы system_server. Поэтому для полной цепочки в Android N требовалась ещё одна уязвимость.

Chrome и Android WebView также раскрывали идентификатор сборки Android в строке агента пользователя, излишне упрощая точное определение версии.

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

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

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

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

Устройство конкурса

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

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

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

Мотивация

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

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

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

Конкурс открылся 13 сентября 2016 года. В объявлении были приведены официальные правила и ответы на часто задаваемые вопросы.

Удачной охоты!

В этой статье рассматривается проблема проектирования в самом сердце XNU — ядра iOS и macOS. Apple выпустила два раунда защитных мер, а затем провела крупный рефакторинг в macOS 10.12.1 и iOS 10.1. На каждом этапе появлялся рабочий эксплойт для выхода из песочницы или повышения привилегий и соответствующий обход защиты.

Немного о портах Mach

Порты Mach — управляемые ядром очереди с несколькими отправителями и одним получателем. Некоторые порты предоставляют тот же API сообщений, но обрабатываются синхронно внутри ядра, почти как системные вызовы. Примером служат порты задач: отправленные им сообщения управляют виртуальной памятью и потоками задачи. У каждого процесса есть порт задачи. MIG генерирует код сериализации для этих принадлежащих ядру интерфейсов.

Низкоуровневый взгляд на IOKit

Пользовательское пространство обычно создаёт клиент IOKit следующей функцией:

IOServiceOpen отправляет созданное MIG сообщение io_service_open_extended порту IOService. Поскольку назначение принадлежит ядру, ловушка Mach непосредственно вызывает его обработчик ядра.

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

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

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

Проверка документации

Расширение Apple AppleSamplePCI демонстрировало небезопасный шаблон:

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

Создание висячего task_t

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

Родительский и созданный через fork дочерний процесс создают общий порт, временно сохраняя право отправки в специальном слоте bootstrap_port. Дочерний процесс восстанавливает слот и устанавливает двунаправленный IPC. Для создания висячего указателя затем требуется:

1. Родитель создаёт дочерний процесс через fork.

2. Дочерний процесс отправляет родителю свой порт задачи и ждёт.

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

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

5. В пользовательском клиенте остаётся висячий указатель task_t.

Первый эксплойт

IOSurfaceRootUserClient был особенно полезен и доступен из песочниц процесса визуализации Safari и GPU Chrome в OS X. IOSurface оборачивает буферы общей памяти. Внешний метод 0, create_surface, принимает словарь; следующие ключи заставляют его обернуть существующие страницы:

Внутри создаётся IOMemoryDescriptor:

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

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

Сборка эксплойта

Структуры задач имеют отдельную зону ядра, что делает повторное использование предсказуемым. После завершения дочернего процесса эксплойт многократно выполнял fork и запускал двоичные файлы setuid-root, пока один из них не занимал висячую структуру.

Целью был указатель на функцию __cleanup в libc, вызываемую при завершении процесса. Эксплойт предоставлял заполненный канал как stderr и заставлял целевой процесс вывести ошибку, приостанавливая его перед завершением. Родитель отображал данные libc через IOSurface и заменял __cleanup гаджетом, который прибавлял большую константу к RSP и возвращался в управляемый атакующим argv. Цепочка инструкций ret стабилизировала ROP-стек, вызывавший setuid(0) и execve("/bin/bash") в разных версиях OS X.

Этот примитив также давал произвольные entitlements, позволяя загружать неподписанные расширения ядра с помощью более раннего приёма CVE-2016-1757. Fork и выполнение setuid были лишь удобными средствами, а не обязательными условиями: любые два сотрудничающих процесса с IPC Mach и доступом к IOSurface могли активировать ошибку, а повторное использование задачи могло обеспечиваться привилегированной службой launchd или CrashReporter.

Apple исправила множество отдельных случаев в OS X 10.11.6 и iOS 9.3.3 и ограничила передачу порта задачи другого процесса выбранным методам IOKit.

Взгляд с высоты

Добавление task_reference(owningTask) и требование передавать собственный порт задачи создателя исправляло обращение к освобождённой памяти, но не более глубокую ошибку проектирования. Повышающий привилегии execve не выделял новую структуру задачи, а изменял существующий объект на месте. Любой объект ядра, хранивший допустимый указатель на прежде непривилегированную задачу, теперь указывал на привилегированный результат.

XNU — не Unix и не Mach

В чистом микроядре Mach аннулирование старого порта задачи отозвало бы управление при привилегированном exec. Подсистемы внутри ядра XNU обходят накладные расходы IPC: код IOKit, mach_vm, задач, потоков и семафоров преобразует порты в указатели C на границе, после чего подсистемы вызывают друг друга напрямую.

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

Каждый указатель task_t — потенциальная ошибка безопасности

Проблема шире временной безопасности памяти. Во время привилегированного exec объект задачи сохраняется, а его полномочия меняются. Поэтому любой task_t ядра может превратиться в примитив confused deputy.

В куче: переписываем эксплойт IOSurface

Дочерний процесс может создать клиент IOSurface через собственный порт задачи и отправить порт пользовательского клиента родителю. Затем он выполняет двоичный файл setuid-root. Правильно удерживаемый owningTask остаётся тем же объектом, но теперь имеет EUID 0. Родитель отображает данные libc целевого процесса, перезаписывает __cleanup и возобновляет его выполнение точно так же, как раньше.

В этой версии нет гонки и режима отказа с обращением к освобождённой памяти; она обходит защиту 10.11.6 и работает вплоть до OS X 10.11.6. Возможности несколько слабее, поскольку дочерний процесс должен вызвать execve, но хранящиеся в куче указатели — лишь часть поверхности атаки.

В стеке: эксплуатация task_threads

Метод MIG task_threads возвращает права отправки на каждый поток задачи:

Сгенерированная обёртка получает и временно удерживает указатель задачи:

task_threads собирает значения thread_t со ссылками, а затем превращает их в порты:

Тем временем привилегированный exec заменяет порт задачи и каждый порт потока. Эксплуатируемое чередование выглядит так:

1. Процесс A преобразует старый порт задачи B и сохраняет указатель задачи.

2. B выполняет код setuid-root и аннулирует старый порт задачи.

3. B устанавливает новые порты для своих теперь привилегированных потоков.

4. A преобразует удерживаемые указатели потоков в эти новые порты и возвращает права отправки на них.

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

Второй раунд защитных мер

iOS 10 и macOS 10.12 связали время жизни пользовательского клиента с создавшей его задачей. Сервер MIG ядра также сохранял снимок exec_token для задачи, представленной первым портом запроса, и отклонял ответ, если привилегированный exec изменял этот токен во время выполнения метода:

У этой защиты было три пробела:

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

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

3. Она блокировала полезные возвращаемые значения, но не методы, которые непосредственно изменяли задачу во время гонки с exec.

Эксплуатация защит второго раунда

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

Процесс A многократно вызывает этот метод со старым портом задачи B, пока B выполняет двоичный файл setuid. Обёртка сначала преобразует порт в удерживаемый task_t; затем реализация берёт блокировку задачи и устанавливает переданный порт исключений. Привилегированный exec использует ту же блокировку, аннулирует старый порт задачи, увеличивает exec_token и очищает непривилегированные обработчики исключений.

Нужный порядок:

1. A преобразует старый порт задачи до exec.

2. B берёт блокировку задачи, аннулирует порт, очищает действия исключений и освобождает блокировку.

3. A берёт блокировку и устанавливает порт исключений атакующего в теперь привилегированную задачу.

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

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

Эксплойт выделяет память RWX в этой задаче и устанавливает заглушку шелл-кода:

Она восстанавливает пригодное ограничение стека, не позволяет Bash сбросить привилегии и запускает оболочку. Цепочка надёжно работала на macOS и OS X 10.12.0 и более ранних версиях.

Окончательное исправление

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

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

В статье описана мера Chrome для Windows, разрабатывавшаяся десять месяцев: запрет доступа к Win32k из процессов подключаемых модулей. Она появилась для Windows 10 в Chrome M54 и вскоре заблокировала этап выхода из песочницы в цепочке, применявшейся в реальных атаках.

Проблема Win32k

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

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

Причина историческая. В ранней Windows NT большая часть оконного кода находилась в пользовательском режиме. Ради производительности NT 4 перенесла значительную часть в ядро, создав win32k.sys до современного усиления безопасности Microsoft. В итоге крупный хрупкий компонент ядра остался доступен процессам GUI в песочнице.

Windows 8 ввела System Call Disable Policy, способную полностью запретить доступ к таблице Win32k. Обычные системные вызовы остаются доступны, но исчезает большой класс точек входа ядра.

Изначально ни одно стандартное приложение Windows не использовало политику, а адаптация Chrome потребовала архитектурной работы. Для изоляции процессов отрисовки обработку шрифтов GDI заменили пользовательской DirectWrite. Примерно через два года Chrome включил блокировку Win32k для этих процессов.

Проблемы Flash в Chrome

Chrome разбирает веб-содержимое в защищённых процессах отрисовки. Flash и PDFium работали в процессах подключаемых модулей PPAPI, которым всё ещё требовался Win32k, оставляя очевидный пробел. Flash был вероятной точкой выполнения кода, а Win32k — сравнительно простым выходом из песочницы.

Утечка Hacking Team в июле 2015 года подтвердила именно такую цепочку: неисправленный эксплойт Flash, а затем выход через Win32k. Хотя обе ошибки устранили, запрет Win32k для PPAPI мог удалить весь класс цепочек.

Анализ проблемы

Приложения обращаются к Win32k главным образом через USER32, GDI32 и IMM32. Необходимо было найти и заменить каждый вызов этих DLL из подключаемых модулей и Pepper.

Использовались два метода:

1. Статическая проверка импорта Pepper Flash и других DLL модулей.

2. Динамическое тестирование под WinDbg с точками останова на заглушках системных вызовов NtUser* и NtGdi*, пока Flash и PDFium обрабатывали разнообразное содержимое.

Почти каждый наблюдавшийся вызов перечислял шрифты напрямую или через PPAPI. Flash также содержал остаточный код OpenSSL, использовавший окно рабочего стола как источник энтропии, что никогда не могло работать внутри песочницы Chrome.

Перечисление шрифтов PPAPI заменить было несложно. Chrome уже поддерживал DirectWrite, а Flash и PDFium отрисовывали большинство глифов собственными реализациями TrueType вроде FreeType. Поддержку DirectWrite расширили на PPAPI.

PDFium мог повторно использовать код шрифтов из реализаций Linux и macOS. Прототип для Flash заменял каждый шрифтовой API GDI на DirectWrite. Для надёжного решения Google и Adobe расширили существующий Pepper API pp::flash::FontFile, прежде реализованный только в Linux, на Windows.

Обречённое управление правами

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

HDCP шифрует видео между выходом GPU и дисплеем. В Windows ему нужен небольшой набор API Win32k. Первоначальный анализ пропустил их, поскольку защищённое содержимое не тестировалось, а Flash динамически разрешал OPMGetVideoOutputsFromHMONITOR через LoadLibrary и GetProcAddress. В итоге dxva2.dll вызывала функции вроде NtGdiCreateOPMProtectedOutputs.

В идеале Chrome предоставил бы новый API HDCP, который приняли бы Adobe DRM и Widevine. Организационные ограничения и доступ к исходному коду делали это непрактичным, поэтому брокер песочницы Chrome перенаправлял вызовы в процесс без блокировки Win32k.

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

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

Это восстановило защищённое воспроизведение Flash и Widevine и позволило включить блокировку.

Избегаем #yolosec

Реализация была лишь частью выпуска защиты для миллионов пользователей. Блокировка PPAPI затрагивала Flash, PDFium, предварительный просмотр печати и Widevine, поэтому требовалось измерить реальную стабильность и функциональность.

Chrome Variations может удалённо включать эксперимент случайной группе пользователей, возвращающих метрики. Группы A/B позволили сравнить сбои, зависания и скорость запуска сначала на каналах Beta, Dev и Canary.

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

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

Chrome M54 по умолчанию включил блокировку Win32k для PPAPI в Windows 10 с аварийным удалённым выключателем. В M56, запланированном на январь 2017 года, отключить её мог только параметр командной строки, выключающий всю блокировку Win32k, включая процессы отрисовки.

Итоги

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

Windows 10 Anniversary Edition добавила фильтр системных вызовов Win32k, сокращавший поверхность без полного запрета таблицы. Edge применял его, но Microsoft ограничила функцию специально подписанными исполняемыми файлами. Кроме того, было неясно, полностью ли фильтр блокировал наблюдавшийся эксплойт или только конкретный известный экземпляр. Полный запрет сильнее: следующий уязвимый вызов не может случайно остаться разрешённым.

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

Благодарности

Проект зависел от множества участников, особенно:

• Ананты Нараянана Айенгара, внедрившего исходную защиту Win32k процессов отрисовки;

• Уилла Харриса, управлявшего Variations и анализом сбоев;

• Сина Чжана и команды безопасности Adobe, удаливших обработку шрифтов GDI из Flash;

• команды Widevine, консультировавшей по поведению DRM.

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

Получившийся эксплойт повышал привилегии любого приложения Android до привилегированных контекстов, включая system_server. Ошибка затрагивала код платформ Marshmallow и Nougat и была исправлена как CVE-2016-6707.

Одно устройство, чтобы связать их

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

Поэтому большие объёмы данных можно передавать через дескриптор. Когда одна и та же память должна оставаться общей, Android предоставляет ashmem — устройство Android Shared Memory.

Делиться памятью — значит заботиться

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

ASHMEM_SET_SIZE запоминает любой переданный размер до первого отображения области:

Это значение также возвращается ASHMEM_GET_SIZE. Однако обработчик mmap в ashmem использует размер только для создания вспомогательного файла shmem; сама VMA сохраняет длину, переданную mmap:

Таким образом, разработчики должны сами передавать совпадающие значения. Если отобразить больше, чем размер backing object, создаётся VMA, страницы за его границами вызывают SIGBUS. Более интересные ошибки возникают, когда код считает эти две длины обязательно равными.

Несовпадающие предположения

Крупные объекты Android Bitmap сериализуются через Binder с помощью ashmem. Bitmap_createFromParcel читает управляемые атакующим метаданные, строит SkBitmap, вычисляет размер данных и запрашивает этот объём у Parcel::readBlob:

readBlob отображает переданный дескриптор с длиной, полученной из этих метаданных, а не с размером, сообщаемым ashmem:

Затем конструктор Bitmap забывает длину отображения и вместо неё сохраняет ASHMEM_GET_SIZE:

При уничтожении он снимает отображение с сохранённым размером ashmem:

Метаданные bitmap управляют длиной mmap, а дескриптор — длиной munmap. Короткое отображение со значительно большим размером backing object приводит к тому, что при уничтожении снимается отображение с произвольного последующего диапазона виртуальных адресов. munmap допускает дыры, поэтому диапазон не обязан быть одним непрерывным отображением. Атакующий может снова занять удалённые адреса управляемыми отображениями, превратив примитив в обращение к освобождённой памяти. Такие специально созданные объекты называются BitUnmap.

Разработка стратегии эксплуатации Поиск целевой службы

Цель должна принимать транзакцию Binder, десериализующую Bitmap или содержащий его Bundle, желательно без проверки разрешений. system_server размещает множество служб, включая Notification Manager. Любое приложение, даже изолированное, может опубликовать уведомление с изображениями.

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

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

Bitmap ashmem создаются функцией mmap, которая выбирает самый высокий достаточно крупный свободный участок ниже TASK_SIZE, начиная с mm->mmap_base. Обычные объекты кучи C++ или Java плохо подходят в качестве целей, поскольку потребовалось бы восстанавливать соседние выделения, а для эксплуатации таблиц виртуальных функций пришлось бы обходить ASLR и NX.

Идеальная цель должна сама выделяться через mmap, допускать замену без восстановления соседей, непосредственно управлять выполнением и не требовать характерных для цели утечек адресов. Журналирование всех вызовов mmap и стеков вызовов указало на стеки потоков.

На волоске

Bionic выделяет pthread_internal_t каждого потока, стек и защитную страницу в одном отображении:

Замена стека приостановленного потока подготовленным ROP-стеком непосредственно даёт выполнение.

AudioService::loadSoundEffects, доступная без разрешений, создаёт несколько потоков system_server. Эксплойт нацелен на SoundPoolThread, поскольку он создаётся первым, блокируется в futex на условной переменной, не касаясь своего стека, и завершается при выгрузке звуковых эффектов. Атакующий может заменить стек, пока поток заблокирован, затем вызвать unloadSoundEffects, чтобы разбудить и безопасно пожертвовать им.

Короткая ROP-цепочка

До Android 7 ROP могла отобразить переданный дескриптор ashmem как исполняемый и перейти к его полезной нагрузке. Политика SELinux в Nougat запрещала execmem, исполняемую ashmem и исполняемые отображения tmpfs для system_server:

Можно было создать длинную чистую ROP, но в этом не было необходимости. system_server мог выполнять файлы с меткой dalvikcache_data_file:

Создавать такую метку мог только installd, но system_server мог через сокет приказать installd оптимизировать произвольный источник в произвольное назначение. Ещё проще было использовать уже имевший эту метку оптимизированный файл атакующего приложения. Статический байтовый массив переживал оптимизацию без изменений, поэтому встроенный в APK шелл-код появлялся в исполняемом файле, который ROP-цепочка могла найти и отобразить.

Точное смещение стека измерялось без догадок: атакующий создавал собственный SoundPoolThread, ждал его командного цикла и сравнивал поле SP в /proc/$pid/stat с базовым адресом стека этого потока.

Обход необходимости обходить ASLR

Приложения Android и system_server создаются через fork из zygote, которая предварительно загружает общие библиотеки. Унаследованные отображения имеют одинаковые адреса у атакующего и цели. Поэтому ROP-гаджеты можно выбрать из собственных библиотек атакующего, происходящих от zygote, и без изменений использовать в system_server.

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

Формирование адресного пространства

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

Атакующий выделяет непрерывную последовательность bitmap, удаляет одно уведомление и вызывает удалённую сборку мусора небольшими транзакциями Binder. Так создаётся одна дыра размера thread_size:

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

BitUnmap отображает только thread_size байт, но сообщает размер backing object 2 * thread_size. Его уничтожение снимает отображение и с него самого, и с соседнего стека потока:

Наконец, управляемый bitmap размера 2 * thread_size повторно занимает оба отображения с поддельными pthread_internal_t и ROP-стеком:

Собираем всё вместе

Полная цепочка:

1. Построить ROP-стек из библиотек, загруженных zygote.

2. Выгрузить существующие звуковые эффекты и закрыть старый SoundPoolThread.

3. Заполнить дыры и выделить последовательные bitmap размера thread_size.

4. Удалить один bitmap и принудительно вызвать удалённую GC, чтобы открыть управляемую дыру.

5. Снова загрузить звуковые эффекты, чтобы стек нового потока попал в эту дыру.

6. Открыть вторую дыру непосредственно перед стеком.

7. Вставить BitUnmap, чьё отображение равно thread_size, а размер ashmem вдвое больше.

8. Принудительно вызвать GC, чтобы BitUnmap снял отображение с себя и целевого стека.

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

10. Выгрузить звуковые эффекты, подать сигнал условной переменной и возобновить поток на поддельном стеке.

Послесловие

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

Хронология

Об эксплойте сообщили в программу вознаграждений за уязвимости Chrome в сентябре 2016 года. Проблема Chromium 648971 содержит более подробное описание и эксплойт.

Однобайтовое переполнение в библиотеке DNS

Менеджер сети Chrome OS, shill, предоставлял HTTP-прокси на случайном TCP-порту localhost. Позже прокси удалили, но его реализация принимала необычно свободный синтаксис HTTP и использовала c-ares для разрешения DNS.

В построителе запросов c-ares было однобайтовое переполнение:

Он преобразует имя хоста с точками в метки DNS в буфере malloc. Каждая метка получает байт длины, а разделяющие точки исчезают. Размер выделения фактически вычисляется как strlen; для обычной последней метки резервируется дополнительный байт её длины.

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

Эксплойт из JavaScript?

shill работал с правами root, поэтому прямой JavaScript-эксплойт мог заменить трёхэтапную цепочку «процесс отрисовки → браузер → root» одним шагом. Его сбой не завершал Chrome, а служба автоматически перезапускалась.

Обычно Chrome не отправляет заголовок Host, заканчивающийся на \.. Вместо этого эксплойт использовал WebRTC TURN — бинарный протокол, поле имени пользователя которого могло содержать данные, напоминающие HTTP. Свободный парсер Shill принимал их.

Прокси слушал случайный порт. TURN также использовался для сканирования localhost по времени подключения. Особый случай самоподключения TCP в Linux создавал ложные срабатывания, когда порты источника и назначения случайно совпадали; повторные попытки сокращали результат до настоящего прослушиваемого порта.

Подготовка кучи была сложнее. Прокси хранил не более 0x7f заголовков в векторе строк, ограничивал отдельные заголовки значением 0x800 байт, а пакеты TURN — 0x8000, пересылал и освобождал их. Одновременно он принимал только одного клиента. Шесть подключений, или этапов, должны были размещать выделения по повторяемым адресам, несмотря на изменения расположения.

Дыра 0x820

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

На первом этапе создаётся постоянная дыра размером 0x820 байт:

Красные фрагменты выделены, зелёные свободны, а голубой — верхний фрагмент dlmalloc. Сначала выделяются четыре фрагмента по 0x410. Первый заменяется нижележащим выделением вектора заголовков, которое сохраняется между подключениями; четвёртый становится постоянным входным буфером сервера. Закрытие соединения освобождает два средних фрагмента заголовков по 0x410 и объединяет их в 0x820.

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

Перекрывающиеся фрагменты

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

Перезаписанный младший байт размера меняет интерпретацию и объединение соседних фрагментов в dlmalloc. Повторное выделение создаёт фрагменты, перекрывающие стабильную область 0x820:

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

ASLR

К четвёртому этапу два фрагмента 0x2a0 являются единственными обычными элементами своего списка свободных блоков dlmalloc наряду со статически выделенной головой списка libc. Поэтому их указатели fd и bk раскрывают как другой фрагмент, так и libc.

Один фрагмент 0x2a0 перекрывает управляемый HTTP-заголовок размером 0x820. Подконтрольный атакующему вышестоящий прокси получает заголовок и передаёт содержащиеся в нём указатели распределителя обратно JavaScript:

Эти значения раскрывают адрес стабильного слота 0x820 и базовый адрес libc, побеждая ASLR.

Переход к root

Этапы 5 и 6 превращают перекрытие в управление потоком выполнения:

Цель — BindState, содержащий указатель функции обратного вызова и связанные аргументы. Размер его фрагмента равен 0x40. Эксплойт освобождает и объединяет область 0x2d0 в 0x810, удаляет её из текущего списка свободных блоков и с помощью перекрывающихся данных 0x820 подделывает её размер как 0x40.

Освобождение поддельного фрагмента и выделение BindState размещают объект внутри известной области 0x820. Последняя перезапись меняет его обратный вызов на system() из libc, а первый аргумент — на команду оболочки, хранящуюся в том же стабильном слоте. Обратный вызов срабатывает примерно через 30 секунд и выполняет команду с правами root.

Ошибка устойчивости

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

Цепочка закрепления напоминала прежний эксплойт geohot и объединяла символические ссылки, dump_vpd_log и modprobe. Задание init записывало сведения о машине во время загрузки:

UI_MACHINE_INFO_FILE находился в доступном для записи /var, и его можно было заменить символической ссылкой. dump_vpd_log --full --stdout выводил управляемый атакующим файл раздела состояния /mnt/stateful_partition/unencrypted/cache/vpd/full-v2.txt, позволяя записать произвольное содержимое через эту символическую ссылку во время загрузки.

Обычно /var/run указывает на изменчивый /run. Эксплойт перенаправлял его в постоянный /var/real_run и с помощью дополнительных символических ссылок компенсировал проблемы служб, запутанных этим изменением.

Файл конфигурации modprobe.d

Прямая запись в /proc/sys/kernel/modprobe больше не работала, поскольку последующая запись udevadm заменяла значение. Вместо этого эксплойт создавал /run/modprobe.d, интерпретируемый modprobe. Его снисходительный парсер игнорирует повреждённые строки, но учитывает:

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

Поздний modprobe

Задание сведений о машине выполнялось после обычной загрузки модулей. Чтобы поздно запустить modprobe, эксплойт создавал символьное устройство с неизвестным старшим номером 173. Обращение к нему заставляет ядро запросить char-major-173-0. Часто используемый путь /var/lib/metrics/uma-event становился символической ссылкой на это устройство.

Раздел состояния был подключён с флагом nodev, поэтому во время запуска устройство требовалось переместить в /dev. Путь init cryptohomed предоставлял такую возможность:

Устройство создавалось как /mnt/stateful_partition/home/.shadow/attestation.epb, а /mnt/stateful_partition/unencrypted/preserve/attestation.epb указывал на /dev/net. Cryptohomed перемещал устройство туда. /dev/net использовался вместо /dev, поскольку задание меняло владельца цели и иначе нарушило бы работу Chrome.

Итоговая цепочка загрузки:

1. dump_vpd_log создавал /run/modprobe.d с командой root.

2. cryptohomed перемещал устройство с неизвестным старшим номером в /dev/net.

3. Код метрик обращался к символической ссылке uma-event.

4. Ядро вызывало modprobe для char-major-173-0.

5. Modprobe выполнял настроенную команду с правами root.

Исправления

Исправления охватили каждый уровень:

• c-ares исправила вычисление длины для экранированной точки и в Chrome OS, и в основном проекте.

• HTTP-прокси Shill был удалён.

• WebRTC TURN усилили, чтобы произвольные имена пользователей не могли достигать TCP-портов localhost.

• Соответствующее поведение сведений о машине, cryptohomed и символических ссылок ужесточили в нескольких изменениях Chrome OS.

Вместе патчи устранили точку входа повреждения памяти, транспорт JavaScript и цепочку закрепления.

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

Samsung KNOX добавила защитный гипервизор Real-Time Kernel Protection (RKP), обеспечивающий целостность во время работы устройства. В этой статье анализируется RKP и описываются уязвимости, обходившие каждый основной механизм. Samsung исправила отчёты в январском Security Maintenance Release и тесно сотрудничала с Project Zero над первопричинами и дальнейшими улучшениями.

Основы HYP

ARMv8 разделяет Normal World на уровни исключений. Приложения Android работают на EL0, Linux — на EL1, а RKP — на EL2, или в режиме HYP:

EL0 вызывает EL1 через supervisor call (SVC), а EL1 вызывает EL2 через hypervisor call (HVC). Hypervisor Configuration Register уровня EL2, HCR_EL2, может перехватывать выбранные операции EL1 и решать, эмулировать или отклонять их.

EL2 также предоставляет второй этап преобразования адресов. Таблицы EL1 сопоставляют виртуальные адреса с промежуточными физическими адресами и применяют биты доступа, XN и PXN. Затем закрытые таблицы EL2 сопоставляют IPA с физическими адресами:

Так RKP может запретить EL1 доступ к выбранным физическим диапазонам даже после компрометации ядра.

Создание исследовательской платформы

Инструкции HVC можно выполнять только с EL1. Исследовательская цепочка сначала использовала более ранний эксплойт system_server, а затем простое переполнение стека в привилегированной записи sysfs для достижения ядра. ROP-обёртка execute_in_kernel подготавливала аргументы функции ядра, вызывала её и возвращала результаты в пользовательское пространство.

В сочетании с обёрткой шелл-кода для system_server получилась многократно используемая среда, способная вызывать произвольные функции ядра и команды RKP. Тестирование проводилось на обновлённом Exynos Galaxy S7 Edge модели SM-G935F со сборкой XXS1APG3.

Защита 1: KASLR

KNOX 2.6 рандомизировала физический и виртуальный базовые адреса ядра одним смещением при загрузке. Для раскрытия этого смещения достаточно одного известного указателя ядра. Linux обычно выводит указатели с регистрозависимым спецификатором %pK, чьё поведение управляется kptr_restrict.

Код debugfs pm_qos от Samsung, доступный для чтения system_server, по ошибке использовал строчную форму %pk:

Опечатка приводила к выводу необработанных указателей. Вычитание известного смещения символа давало смещение KASLR.

Защита 2: загрузка произвольного кода ядра

RKP должна была обеспечивать:

• PXN на каждой странице, кроме кода ядра;

• отсутствие исполняемых данных ядра;

• отсутствие доступного для записи кода ядра;

• код ядра только для чтения на втором этапе;

• таблицы преобразования EL1 только для чтения.

Для аудита первого этапа эксплойту требовался TTBR1_EL1. Подходящих гаджетов ядра было мало, но Exynos запускала EL2 из EL1, встраивая полный образ RKP в текст ядра, а затем копируя его в фиксированную физическую область. Встроенная копия содержала гаджеты для чтения и записи большинства управляющих регистров EL1:

Эксплойт прочитал TTBR1_EL1, выгрузил иерархию преобразования и обнаружил физический диапазон 0x80000000–0x81400000, отображённый секциями по 2 Мбайт как доступный EL1 для чтения, записи и выполнения.

Начальная таблица второго этапа, встроенная в RKP, тождественно отображала тот же диапазон с S2AP=11 и без XN:

Запись в активный текст ядра всё же вызывала ошибку, поскольку позднее EL1 вызывал RKP_INIT, передавая _text, _etext, таблицы страниц, rodata и другие диапазоны:

RKP делала доступным только для чтения на втором этапе лишь окончательный смещённый интервал _text–_etext:

Для KASLR требовалось резервировать значительно более широкое исполняемое окно. Участки перед _text и после _etext оставались RWX на обоих этапах:

Новый код EL1 можно было просто записать в эти неиспользуемые исполняемые диапазоны, обойдя политику загрузки кода RKP.

Защита 3: обход управления памятью EL1

RKP помечала таблицы страниц первого этапа доступными только для чтения на втором этапе и паравиртуализировала Linux так, что каждое обновление PGD, PMD или PTE превращалось в запрос RKP. Это защищает содержимое таблиц, но не обязательно управляющие регистры, которые выбирают и интерпретируют их.

RKP устанавливала HCR_EL2.TVM, перехватывая запись в выбранные регистры управления памятью, но неправильно обрабатывала SCTLR_EL1 и TCR_EL1:

Очистка SCTLR_EL1.M отключает преобразование первого этапа. Тогда адреса EL1 действуют как IPA без проверок прав первого этапа, фактически делая всю отображённую на втором этапе память RWX на первом:

TCR_EL1 давал более тонкий обход. Linux обычно использовала гранулы преобразования размером 4 Кбайт, и RKP защищала только одну страницу 4 Кбайт при установке EL1 новой таблицы:

Изменение TCR_EL1.TG0 или TG1 на гранулу 64 Кбайт делало корневую таблицу 64-килобайтной. RKP по-прежнему защищала только 4 Кбайт, оставляя 60 Кбайт доступными для записи управляемых атакующим дескрипторов:

Встроенный образ RKP предоставлял необходимые гаджеты для регистров. Доказательство концепции полностью отключало MMU первого этапа EL1.

Защита 4: доступ к памяти, не отображённой на втором этапе

RKP исключала из преобразования второго этапа чувствительную периферийную прошивку, собственную память и свои таблицы второго этапа. Доступ с EL0/EL1 должен был вызывать ошибку:

Одна команда RKP, предназначенная для защиты начальной страницы учётных данных, принимала указатель EL1:

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

Доказательство концепции повторно отображало и читало физическую память RKP с EL1.

Улучшение устройства RKP

Exynos следует использовать модель загрузки Qualcomm: проверять EL2 в загрузчике и запускать его из EL3 до EL1. Это устраняет встроенный образ EL2 с гаджетами и не позволяет ранней компрометации EL1 подорвать инициализацию гипервизора. В качестве временной меры Samsung планировала стирать встроенную копию после запуска.

Собственный код RKP был доступен для записи и выполнения в TTBR0_EL2, а SCTLR_EL2.WXN был очищен. Поэтому несколько не заявленных ошибок повреждения памяти EL2 позволяли непосредственно переписать код гипервизора. Код только для чтения в сочетании с WXN не исключил бы эксплуатацию, но повысил бы её стоимость.

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

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

Современные графические драйверы сложны и предоставляют многообещающую поверхность атаки для повышения привилегий и выхода из песочницы процессов с доступом к GPU, например процесса GPU в Chrome. В ходе этого исследования драйверов NVIDIA режима ядра для Windows в рамках проекта на 20% рабочего времени Project Zero было обнаружено 16 уязвимостей.

Интерфейсы WDDM ядра

Компонент графического стека в ядре представляет собой минипорт-драйвер дисплея. Windows связывает его с приложениями и подсистемой ядра DirectX следующим образом:

В DriverEntry минипорт заполняет структуру DRIVER_INITIALIZATION_DATA обратными вызовами производителя и передаёт её dxgkrnl.sys через DxgkInitialize. Ядро DirectX может вызывать эти функции, а некоторые из них также доступны из пользовательского режима.

DxgkDdiEscape

DxgkDdiEscape — очевидная цель для аудита. Пользовательский режим передаёт произвольные данные производителя, фактически выполняя IOCTL. NVIDIA поддерживала около 400 команд escape:

Внутренние структуры можно представить так:

Каждая структура pPrivateDriverData начинается с заголовка:

Команды идентифицируются 32-разрядным кодом и группируются по старшему байту со значениями от 1 до 9. Диспетчер проверяет заголовок относительно PrivateDriverDataSize и обычно сравнивает размер полезной нагрузки с NvEscapeCodeInfo.expected_size. Нулевой ожидаемый размер обозначает входные данные переменной длины и оставляет проверку обработчику, из-за чего возникает несколько ошибок.

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

DxgkDdiSubmitBufferVirtual

В Windows 10 и WDDM 2.0 появилась функция DxgkDdiSubmitBufferVirtual для виртуальной памяти GPU, заменившая прежние пути отправки и отрисовки. Она принимает от драйвера пользовательского режима данные команд, зависящие от производителя, и содержала одну уязвимость.

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

Доступные устройства

NVIDIA также устанавливала устройства, которые мог открыть любой пользователь:

• \\.\NvAdminDevice, предположительно используемое NVAPI; многие обработчики перенаправляют вызовы в команды escape.

• \\.\UVMLiteController и связанные устройства процессов для унифицированной памяти; обнаружена одна ошибка.

• \\.\NvStreamKms, устанавливаемое по умолчанию вместе с GeForce Experience, если не отменить выбор; обнаружена одна ошибка.

Более интересные ошибки

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

NvStreamKms

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

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

Однако канонические UNC-пути WebDAV могут сохранять прямые косые черты. Они обходят поиск обратной косой черты и превращают всю оставшуюся часть пути в одно слишком длинное «имя файла»:

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

Эксплуатация оказалась несложной, поскольку в NvStreamKms.sys не было защитных cookie стека. Доказательство концепции запускало поддельный сервер WebDAV, с помощью ROP переносило выполнение в пользовательский буфер, выделяло память RWX и исполняло шелл-код повышения привилегий.

Неправильная проверка в UVMLiteController

\\.\UVMLiteController был доступен даже из изолированного процесса GPU Chrome. Его обработчики METHOD_BUFFERED записывали результаты непосредственно через Irp->UserBuffer, вопреки рекомендациям Microsoft.

Ядро проверяет предоставленный пользователем выходной диапазон, но обработчики не выполняли собственных проверок длины. Вызывающая сторона могла передать нулевую длину с произвольным адресом, который проходил ProbeForWrite, и получить ограниченный примитив записи произвольного значения по произвольному адресу. Среди доступных значений были 32-разрядные 0xffff, 0x1f, ноль и 8-разрядный ноль. Простой локальный эксплойт повышения привилегий продемонстрировал этот примитив.

Вектор удалённой атаки?

Количество находок побудило исследовать возможность полностью удалённого доступа через WebGL или аппаратное ускорение видео. Ни одна из уязвимостей не оказалась доступна без предварительной компрометации изолированного процесса. Уязвимые API были низкоуровневыми и находились за такими слоями, как libANGLE, среда выполнения Direct3D и драйвер пользовательского режима, которые обычно формировали корректные аргументы.

Реакция NVIDIA

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

Хронология Разрыв между исправлением и раскрытием

Первые шесть исправлений вышли без подробного бюллетеня; NVIDIA планировала раскрыть сведения через месяц. У атакующих оставалось время исследовать патч до того, как пользователи узнали о его значимости для безопасности. Следующие восемь исправлений появились за пять дней до бюллетеня. NVIDIA, по-видимому, сокращала этот интервал, хотя последующие бюллетени оставались непоследовательными.

Заключение

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

Конкурс Project Zero Prize, объявленный 13 сентября 2016 года, завершился через шесть месяцев без присуждения наград. В этой статье рассказывается о произошедшем и об уроках, которые команда извлекла при разработке конкурсов по безопасности.

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

В этой серии из двух частей рассматриваются однокристальные системы Wi-Fi Broadcom FullMAC. В первой части мы получим удалённое выполнение кода на чипе Wi-Fi. Во второй повысим привилегии с чипа до ядра процессора приложений, полностью скомпрометировав устройство по Wi-Fi без взаимодействия с пользователем.

Чипы Broadcom использовались в Nexus 5/6/6P, флагманах Samsung и всех iPhone начиная с iPhone 4. Тестирование проводилось на актуальном на тот момент Nexus 6P под управлением Android 7.1.1 NUF26K. Broadcom быстро отреагировала и координировала исправления с производителями устройств.

Почему Wi-Fi?

Чипы FullMAC реализуют PHY, MAC и MAC Sublayer Management Entity в прошивке. Это снижает сложность хоста, энергопотребление и затраты на интеграцию, но добавляет в доверенную вычислительную базу проприетарный процессор и большую кодовую базу.

Исследование платформы

Опубликованная Cypress документация BCM4339 раскрыла ARM Cortex-R4, 640 Кбайт ROM для кода прошивки и 768 Кбайт RAM для кучи, данных и исправлений ROM:

Драйвер хоста загружает прошивку RAM из BCMDHD_FW_PATH. ROM можно было выгрузить без изменения драйвера, поскольку команда Broadcom dhdutil membytes читает и записывает память dongle. Исследование NexMon установило, что ROM находится по адресу 0x0, а RAM — по 0x180000. Объединение дампа ROM и файла прошивки дало единый образ IDA.

Анализ прошивки

Broadcom агрессивно экономила место. Символы и большинство строк были удалены, исключительно использовался Thumb-2, а в ROM оставалось менее 300 свободных байт. Области кода, нужные только для инициализации, после загрузки повторно использовались как куча. Фиксированный код и выровненные глобальные данные разделяли RAM на чередующиеся участки кода, данных и кучи.

Символы BCM4339 из NexMon можно было перенести на более новые образы с помощью двоичного сравнения. Открытый драйвер SoftMAC brcmsmac от Broadcom также предоставлял имена и логику общих вспомогательных функций MLME.

Поиск ошибок

Кадры управления Wi-Fi кодируют информацию в Information Element с однобайтовым тегом и однобайтовой длиной. Общая вспомогательная функция bcm_parse_tlvs имела более 110 перекрёстных ссылок; обратная разработка этих мест вызова обнаружила несколько уязвимостей.

Два переполнения стека были связаны с 802.11r Fast BSS Transition и роумингом Cisco CCKM. Они не имели защиты стековыми cookie, но требовали специализированной поддержки сети. Теги возможностей прошивки показывали, что Nexus 6P не поддерживал ни fbt, ни ccx, хотя CCKM поддерживали многие устройства Samsung.

Ещё две ошибки затрагивали Tunneled Direct Link Setup. Поддержка TDLS, обозначаемая betdls или tdls, была широко распространена на устройствах Nexus и Samsung, публично описана в 802.11z и могла активироваться любым узлом в той же сети Wi-Fi.

Основы TDLS 802.11z

TDLS позволяет двум клиентам обмениваться трафиком напрямую, не ретранслируя его через точку доступа. Кадры используют To-DS=0, From-DS=0, Ethertype 0x890d, фиксированный тип полезной нагрузки и категорию, а также однобайтовый код действия:

Узлы обнаруживают друг друга кадрами запроса и ответа, связанными dialog token. Настройка использует трёхстороннее рукопожатие и создаёт TDLS Peer Key. Кадр teardown удаляет отношение.

Защищённые кадры управления TDLS включают Link Identifier, номер последовательности, причину или состояние и FTIE, содержащий Message Integrity Code. Перед вычислением и сравнением MIC получатель заново собирает выбранные Information Element во временном буфере.

Уязвимости

Broadcom выделяла фиксированный 256-байтовый буфер кучи для входных данных MIC, но копировала управляемые атакующим IE без ограничения общей длины. Его могли переполнить и обработка setup response/confirm, и teardown. Вариант teardown позволял записать около 25 управляемых байт за пределами выделения и легче поддавался подготовке кучи.

Устройство кучи

HNDRTE использовала простой аллокатор связанного списка по принципу best fit. Свободные чанки хранили размер и указатель next; выделенные сохраняли размер, но очищали поле next. Выделение вырезалось из конца подходящего свободного чанка, а free вставляла и объединяла соседей без проверок safe unlink.

Пользовательские хуки прошивки записывали каждое выделение и освобождение. Визуализатор снимков RAM восстанавливал свободные и используемые чанки:

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

После настройки оставались две дыры размером 0x11c и 0x124. Во время teardown 256-байтовый буфер MIC занимал наиболее подходящую дыру 0x11c, а его 25-байтовое переполнение достигало заголовка и первых байтов данных следующего чанка:

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

Создание перекрывающегося чанка

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

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

Поиск управляемого выделения

Большинство операций прошивки не выделяли управляемых постоянных данных. Это делал специфичный для производителя код действия TDLS 127. Кадры, начинавшиеся с OUI Wi-Fi Alliance 50:6f:9a, выбирали команду 4 или 5. Команда 4, туннелированный probe request, работала даже без активного сеанса TDLS и выполняла:

Выделение A имело управляемые атакующим размер, содержимое и время жизни.

Linux mac80211 отклоняла эти нестандартные кадры, поэтому в неё добавили поддержку и команду TDLS_VNDR для wpa_supplicant:

Собираем всё вместе

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

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

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

Ещё одно стабильное выделение времени загрузки — консольный буфер 0x400, больше не использовавшийся после инициализации, — содержало шелл-код:

MPU Cortex-R4 была включена, но настраивала каждый диапазон адресов на полный доступ без XN:

Таким образом, куча была исполняемой. Эксплойт заменял консольный чанк шелл-кодом, а обратный вызов таймера — его адресом:

Когда таймер срабатывал, код атакующего выполнялся в прошивке Wi-Fi. Опубликованная безвредная полезная нагрузка записывала магическое значение по адресу RAM прошивки 0x200000, доказывая выполнение.

Итоги

Сложной прошивке Wi-Fi Broadcom не хватало фундаментальных средств защиты: стековых cookie, safe unlink и осмысленных разрешений MPU на выполнение. Broadcom сообщила, что более новые SoC используют MPU и дополнительные аппаратные механизмы и рассматривает дальнейшие меры защиты прошивки.

Вторая часть продолжает путь от контроля над прошивкой Wi-Fi до компрометации ядра операционной системы хоста.

Чтобы продемонстрировать последствия, я создал эксплойт, который при запуске с правами root в одной 64-разрядной гостевой PV-системе выполняет команду оболочки от имени root во всех остальных 64-разрядных PV-системах на той же физической машине, включая dom0.

Предыстория access_ok()

На x86-64 гостевые PV-системы Xen делят виртуальное адресное пространство с гипервизором. В общих чертах расположение памяти выглядит так:

Xen позволяет гостевому ядру выполнять гипервызовы, которые, по сути, являются обычными системными вызовами из гостевого ядра в гипервизор по ABI System V AMD64. Они используют инструкцию syscall и передают до шести аргументов в регистрах. Подобно обычным системным вызовам, гипервызовы Xen часто принимают гостевые указатели как аргументы. Поскольку гипервизор разделяет адресное пространство, гости могут просто передавать гостевые виртуальные указатели.

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

• access_ok(addr, size) проверяет, безопасен ли доступ к переданному гостем диапазону виртуальной памяти.

• __copy_to_guest(hnd, ptr, nr) копирует nr байт из адреса гипервизора ptr в гостевой адрес hnd, не проверяя безопасность hnd.

• copy_to_guest(hnd, ptr, nr) выполняет копирование только в том случае, если hnd безопасен.

В Linux access_ok() проверяет, безопасен ли весь диапазон от addr до addr+size-1 при любом шаблоне доступа. access_ok() в Xen такой гарантии не предоставляет:

Обычно Xen проверяет только, что addr указывает в пользовательское пространство или пространство ядра, не проверяя size. Этого достаточно, когда доступ начинается по addr, линейно продолжается без огромных разрывов и прекращается при первой ошибке: до памяти гипервизора встречается большой неканонический защитный диапазон. Однако гипервызов, обращающийся к гостевому буферу по 64-разрядному смещению, должен применять проверку к правильному смещению. Проверять только весь пользовательский буфер небезопасно.

Xen предоставляет обёртки для массивов в гостевой памяти. guest_handle_okay(hnd, nr) подходит для массива, начинающегося с нулевого элемента; для массива, начинающегося в другом месте, требуется guest_handle_subrange_okay(hnd, first, last).

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

Вытеснение гипервызовов

При тике планировщика Xen должен иметь возможность быстро переключиться с текущего vCPU на vCPU другой виртуальной машины. Нельзя просто прервать гипервызов, который может удерживать spinlock, поэтому длительно работающий код гипервызова добровольно вызывает hypercall_preempt_check().

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

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

memory_exchange()

HYPERVISOR_memory_op(XENMEM_exchange, arg) вызывает memory_exchange(arg) в xen/common/memory.c. Функция позволяет гостю обменивать назначенные физические страницы на новые с другими ограничениями физической непрерывности, что полезно для DMA.

Соответствующие структуры аргументов:

Нас интересуют поля in.extent_start, in.nr_extents, out.extent_start, out.nr_extents и nr_exchanged. Гость обязан инициализировать nr_exchanged нулём, поскольку это одновременно выходное значение и состояние вытеснения гипервызова. При вытеснении memory_exchange() сохраняет туда свой прогресс; следующий вызов использует его для выбора позиции возобновления во входном и выходном массивах.

Изначально memory_exchange() обращалась к этим массивам через непроверяемые вызовы __copy_from_guest_offset() и __copy_to_guest_offset(). Поэтому передача указателей гипервизора позволяла читать и записывать его память. Это было исправлено в 2012 году как XSA-29 (CVE-2012-5513); локальное исправление добавило:

Ошибка

Управляемое гостем 64-разрядное смещение возобновления nr_exchanged выбирает позицию в out.extent_start, куда записывает Xen:

Но guest_handle_okay() проверяет только доступ, начинающийся со смещения ноль; правильной проверкой была guest_handle_subrange_okay(). Поэтому атакующий может записать восьмибайтовое значение по произвольному адресу гипервизора, выбрав:

• exch.in.extent_order = 0 и exch.out.extent_order = 0.

• exch.out.extent_start и exch.nr_exchanged так, чтобы первый находился в пользовательском пространстве, а exch.out.extent_start + 8 * exch.nr_exchanged был целевым адресом. В частности, extent_start = target_addr % 8 и nr_exchanged = target_addr / 8.

• Оба значения nr_extents равными nr_exchanged + 1.

• exch.in.extent_start = input_buffer - 8 * exch.nr_exchanged, где input_buffer — настоящий указатель гостевого ядра на номер физической страницы, принадлежащей гостю.

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

Эксплуатация ошибки: получение контроля над таблицами страниц

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

Для 64-разрядной гостевой PV-системы x86 этого достаточно, поскольку:

• Гость знает настоящие номера физических страниц всех доступных ему страниц.

• Он может отображать действующие таблицы страниц всех четырёх уровней только для чтения; Xen запрещает лишь доступные для записи отображения.

• Xen отображает всю физическую память для записи по адресу 0xffff830000000000, поэтому любую физическую страницу можно записать через physical_address + 0xffff830000000000.

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

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

Выполнение команд оболочки в других виртуальных машинах

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

Сначала эксплойт получает выполнение кода в контексте гипервизора. Непривилегированная инструкция SIDT находит Interrupt Descriptor Table; одну запись можно изменить на DPL 3 и вызвать. Xen поддерживает SMEP и SMAP, поэтому запись не может указывать прямо в гостевую память. Однако контроль таблиц страниц позволяет эксплойту отобразить принадлежащую гостю страницу с шелл-кодом как память supervisor и выполнить её вопреки SMEP. Ожидалось, что будущие процессоры Intel будут поддерживать User-Mode Instruction Prevention, делая SIDT привилегированной.

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

Внедрённый шелл-код выполняется при каждом системном вызове write(). Он проверяет наличие прав root и отсутствие файла блокировки, затем через clone() запускает дочерний процесс, выполняющий произвольную команду оболочки. Доказательство концепции намеренно не выполняет очистку; последующее выключение атакующего домена приводит к аварийному завершению гипервизора из-за перехваченной точки входа.

На следующем снимке показана успешная атака на Qubes OS 3.2. Эксплойт работает в непривилегированном домене test124 и внедряет код в dom0 и виртуальную машину межсетевого экрана:

Заключение

Я считаю, что первопричиной была слабая гарантия безопасности access_ok(). Её текущая форма была зафиксирована в 2005 году, через два года после первого публичного выпуска Xen и задолго до первой XSA. Старый код часто содержит простые слабости, поскольку подвергался меньшему вниманию к безопасности и впоследствии оставался нетронутым.

Оптимизации, влияющие на безопасность и основанные на предположениях, должны надёжно препятствовать нарушению этих предположений. Когда-то access_ok() проверяла пересечение всего диапазона с памятью гипервизора, что предотвратило бы эту ошибку. Коммит 2005 года с описанием «x86_64 fixes/cleanups» изменил её поведение на нынешнее. По-видимому, гипервызовы MEMOP_increase_reservation и MEMOP_decrease_reservation избежали непосредственной уязвимости только потому, что do_dom_mem_op() использовала 32-разрядный nr_extents, — весьма хрупкая защита.

Хотя несколько уязвимостей Xen затрагивали только PV-гостей, поскольку находились в коде только для PV, эта проблема не означает, что доступ к памяти PV-гостя по своей природе сложнее. raw_copy_from_guest() для PV вызывает copy_from_user(), то есть, по сути, проверку границ с последующим устойчивым к ошибкам memcpy. raw_copy_from_guest() для HVM вызывает copy_from_user_hvm(), которая выполняет постраничное копирование, обход гостевых таблиц страниц, поиск кадров, подсчёт ссылок, временные отображения и такие проверки, как защита доступных только для чтения grant mapping. На самом деле доступ к памяти HVM-гостя сложнее.

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

Эта работа отличалась тем, что Uniscribe — малоизвестный компонент пользовательского режима, который, в отличие от реализаций шрифтов ядра в win32k.sys и ATMFD.DLL, не считался широко известным вектором атаки. В этой публикации кратко описывается Uniscribe, объясняется, как мы масштабно фаззили её, и выделяются некоторые находки. Исходные отчёты и образцы для доказательства концепции доступны в трекере проблем Project Zero.

Введение

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

Через несколько дней мы получили образцы, которые, по-видимому, приводили к сбою гостевой Windows в Bochs. Наш конвейер воспроизведения не мог повторить bugcheck. Один результат оказался неожиданным: тестовый случай завершал процесс harness пользовательского режима, не выводя из строя операционную систему. Это указывало либо на ошибку в нашем harness, либо на непредвиденный разбор шрифтов в ring 3. Необработанное исключение возникало здесь:

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

Мы установили, что usp10.dll — процессор сценариев Unicode Uniscribe. Это сравнительно крупный модуль размером от 600 до 800 Кбайт в зависимости от версии и разрядности Windows, отвечающий за отрисовку текста Unicode. С точки зрения безопасности его код восходит к Windows 2000 и включает парсеры C++ сложных структур TrueType/OpenType, отсутствующих в реализации ядра. Он главным образом обрабатывает таблицы Advanced Typography GDEF, GSUB, GPOS, BASE и JSTF, а также частично OS/2, cmap и maxp.

До открытого кода можно добраться простым вызовом DrawText или эквивалентного API с текстом Unicode и управляемым атакующим шрифтом. Специальный API Uniscribe не требуется, что делает компонент полезным вектором атаки в приложениях, отрисовывающих недоверенные шрифты через GDI. Исходный сбой произошёл в программе без кода, специфичного для Uniscribe:

Uniscribe вызывалась внутри user32.dll через библиотеку Language Pack lpk.dll. Большую часть инфраструктуры можно было использовать повторно. Мы отфильтровали корпус, скорректировали мутации и конфигурацию системы и добавили обнаружение сбоев пользовательского режима как в harness, так и в инструментирование Bochs. Через несколько дней более 80 сбоев по уникальным адресам были готовы к сортировке.

Краткий обзор результатов

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

Все ошибки, кроме одной, активировались обычным вызовом DrawText и приводили к повреждению кучи. Проблема 1030 находилась в документированном API ScriptGetFontAlternateGlyphs. Функция не соблюдала cMaxAlternates и могла записать в pAlternateGlyphs больше результатов, чем разрешил вызывающий код. В зависимости от буфера вызывающей стороны переполнение могло затрагивать стек, кучу или статическую память. Эксплуатируемость в значительной степени зависела бы от устройства клиента и параметров компиляции, а настоящие клиенты функции были неясны.

Мы также выделили 27 уникальных сбоев недопустимого чтения не-NULL адресов с потенциалом раскрытия информации. Из-за их количества подробный анализ был невозможен, поэтому мы сгруппировали их по верхнему адресу исключения и зарегистрировали вместе как проблему 1031:

• usp10!otlMultiSubstLookup::apply+0xa8

• usp10!otlSingleSubstLookup::applyToSingleGlyph+0x98

• usp10!otlSingleSubstLookup::apply+0xa9

• usp10!otlMultiSubstLookup::getCoverageTable+0x2c

• usp10!otlMark2Array::mark2Anchor+0x18

• usp10!GetSubstGlyph+0x2e

• usp10!BuildTableCache+0x1ca

• usp10!otlMkMkPosLookup::apply+0x1b4

• usp10!otlLookupTable::markFilteringSet+0x1a

• usp10!otlSinglePosLookup::getCoverageTable+0x12

• usp10!BuildTableCache+0x1e7

• usp10!otlChainingLookup::getCoverageTable+0x15

• usp10!otlReverseChainingLookup::getCoverageTable+0x15

• usp10!otlLigCaretListTable::coverage+0x7

• usp10!otlMultiSubstLookup::apply+0x99

• usp10!otlTableCacheData::FindLookupList+0x9

• usp10!ttoGetTableData+0x4b4

• usp10!GetSubtableCoverage+0x1ab

• usp10!otlChainingLookup::apply+0x2d

• usp10!MergeLigRecords+0x132

• usp10!otlLookupTable::subTable+0x23

• usp10!GetMaxParameter+0x53

• usp10!ApplyLookup+0xc3

• usp10!ApplyLookupToSingleGlyph+0x6f

• usp10!ttoGetTableData+0x19f6

• usp10!otlExtensionLookup::extensionSubTable+0x1d

• usp10!ttoGetTableData+0x1a77

В действительности это была 21 ошибка, исправленная как CVE-2017-0083, CVE-2017-0091, CVE-2017-0092 и CVE-2017-0111 — CVE-2017-0128 в MS17-011.

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

Корпус входных данных, конфигурация мутаций и изменения harness

Хороший корпус входных данных особенно важен без обратной связи по покрытию, поскольку корпус не может эволюционировать к более эффективной форме. Мы повторно использовали файлы, ранее обнаружившие 18 ошибок ядра Windows. Они были выделены из найденных в интернете шрифтов с помощью инструментированной сборки FreeType2: 14 848 файлов TrueType и 4659 OpenType общим объёмом 2,4 Гбайт.

Для Uniscribe мы сохранили только файлы, содержащие хотя бы одну из таблиц GDEF, GSUB, GPOS, BASE или JSTF. Итоговый корпус включал 3768 шрифтов TrueType и 2520 OpenType и занимал 1,68 Гбайт.

Мутация была похожа на кампанию против ядра: стандартные алгоритмы bitflipping, byteflipping, chunkspew, special ints и binary arithmetic с заранее рассчитанными диапазонами коэффициентов мутации для отдельных таблиц. Для Uniscribe мы добавили мутации BASE и JSTF.

Гостевой harness уже отображал каждый глиф в нескольких кеглях и запрашивал множество свойств. Для расширения покрытия Uniscribe мы добавили вызовы ScriptCacheGetHeight, ScriptGetFontProperties, ScriptGetCMap, ScriptGetFontAlternateGlyphs, ScriptSubstituteSingleGlyph и ScriptFreeCache. Так была обнаружена общая ошибка ScriptGetFontAlternateGlyphs. Мы удалили GetKerningPairs и GetGlyphOutline, чья значимая логика находилась в ядре и лишь замедляла бы эту кампанию пользовательского режима.

Обнаружение сбоев

Мы отключили Special Pools для win32k.sys и ATMFD.DLL, где они создавали накладные расходы пользовательского режима без пользы, и включили PageHeap в Application Verifier для harness. Это улучшило обнаружение недопустимых обращений к памяти и сделало воспроизведение и устранение дубликатов надёжнее.

Поскольку usp10.dll выполнялась в процессе harness, отладчик для наблюдения за вторым процессом не требовался. Обработчик верхнего уровня, установленный через SetUnhandledExceptionFilter, получал фатальные исключения. Он передавал контекст CPU в момент ошибки из ExceptionInfo->ContextRecord инструментированию Bochs через гипервызов отладочной печати и сообщал точный адрес сбоя.

При фаззинге ядра Bochs обнаруживал сбои через обратный вызов BX_INSTR_RESET, поскольку Windows автоматически перезагружалась после bugcheck. Вызов ExitWindowsEx из обработчика исключений пользовательского режима позволил бы повторно использовать этот механизм, но потерял бы адрес сбоя и исключил автоматическое устранение дубликатов. Поэтому мы добавили отдельный гипервызов «обнаружен сбой», передающий адрес инструкции, вызвавшей ошибку. Группировка сбоев по адресу во время сбора значительно сократила последующую обработку и число случаев, требующих ручной проверки.

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

Выводы

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

Работа также демонстрирует переносимость инфраструктуры фаззинга. Большинство компонентов можно повторно использовать для разных целей, особенно в рамках одного файлового формата. Код пользовательского режима Windows можно эффективно фаззить даже при Linux на хосте. Bochs создаёт значительные накладные расходы относительно нативного выполнения, но горизонтальное масштабирование всё равно способно дать чистый прирост числа итераций в секунду.

Другие проблемы, исправленные в тот же вторник обновлений, включая 993 (загрузка кустов реестра ядром), 1042 (EMF+ в GDI+) и 1052 и 1054 (цветовые профили), также были обнаружены фаззингом Windows в Bochs с другими образцами, harness и стратегиями мутации.

Ссылки

1. Одна уязвимость в шрифтах, чтобы править всеми

2. Включение QR-кодов в Internet Explorer

3. Год фаззинга шрифтов ядра Windows, часть 1

4. Год фаззинга шрифтов ядра Windows, часть 2

5. Проблемы Uniscribe, исправленные 14 марта 2017 года

6. Анализ CVE-2016-7274

7. Uniscribe.aspx)

8. DrawText

9. Функции Uniscribe.aspx)

Во время фаззинга сетевых интерфейсов ядра Linux с помощью syzkaller я обнаружил уязвимость в пакетных сокетах. CVE-2017-7308 — ошибка знаковости, приводящая к эксплуатируемой записи за границами объекта в куче. Специально подобранные параметры PACKET_RX_RING для сокета AF_PACKET с TPACKET_V3 обходят следующую проверку в packet_set_ring():

Ошибка появилась вместе с TPACKET_V3 в августе 2011 года. Попытка отклонять слишком большие пакеты, сделанная в августе 2014 года, оказалась недостаточной; коммит 2b6867c2 исправил её 29 марта 2017 года.

В затронутых ядрах включён параметр CONFIG_PACKET=y. Для создания пакетных сокетов требуется CAP_NET_RAW, но непривилегированный процесс может получить эту capability внутри доступного пространства имён пользователя. Проблема затронула в том числе Ubuntu и Android, хотя Android запрещает недоверенным приложениям использовать пакетные сокеты.

Syzkaller

Syzkaller генерирует программы из системных вызовов по декларативным шаблонам, выполняет их, записывает покрытие, сохраняет входные данные, открывающие новые пути, и мутирует корпус. Он работает с динамическими детекторами: KASAN для ошибок памяти, KMSAN для неинициализированных данных и KTSAN для гонок.

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

За несколько минут syzkaller создал аварийно завершающуюся программу, в которой tp_sizeof_priv фактически равнялся -2:

KASAN сообщил о четырёхбайтовой записи за границей slab в prb_close_block, достигнутой через tpacket_rcv при обработке трафика. Поскольку обращение попадало далеко за исходный блок, стек выделения в отчёте относился к постороннему объекту в месте назначения, а не к переполняемому кольцу.

Введение в сокеты AF_PACKET

Сокеты AF_PACKET отправляют и принимают данные на уровне драйвера устройства, обеспечивая перехват пакетов и реализацию собственных протоколов. Обычные send и recv работают, но PACKET_TX_RING и PACKET_RX_RING создают общую для ядра и пользовательского пространства память для ускоренной передачи. PACKET_VERSION выбирает одну из нескольких схем размещения.

Например, tcpdump выполняет примерно следующее:

Программа создаёт и привязывает пакетный сокет, выбирает TPACKET_V2, создаёт RX-кольцо и отображает его в память. Затем ядро помещает принятые пакеты непосредственно в эту область.

Кольцевые буферы

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

Ядро представляет сокет структурой packet_sock; его кольцо приёма — это packet_ring_buffer, элементы вектора страниц которого указывают на блоки, выделенные buddy allocator.

Для V3 поле rx_ring.prb_bdqc указывает на tpacket_kbdq_core, содержащую размер блока, размер приватных данных, смещение следующего кадра, максимальную длину кадра и таймер вывода блока.

PACKET_VERSION выбирает V3, а PACKET_RX_RING приводит к packet_set_ring(). Последняя проверяет параметры, выделяет вектор страниц и инициализирует tpacket_kbdq_core. При приёме tpacket_rcv() находит кадр через __packet_lookup_frame_in_block(), копирует пакет и продвигает смещение. Заполненные блоки и блоки с истёкшим тайм-аутом передаются пользовательскому пространству.

Уязвимость Ошибка

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

При последующем присваивании 16-битному blk_sizeof_priv сохраняются только младшие два байта. Поэтому атакующий может выбрать любой 16-битный размер приватной области, одновременно обходя проверку.

Последствия

init_prb_bdqc() вычисляет max_frame_len из этого значения. Если сделать BLK_PLUS_PRIV(blk_sizeof_priv) больше размера блока, вычисление переполнится вниз и даст огромный максимальный размер кадра, обходя границу копирования пакета. prb_open_block() также использует его для вычисления nxt_offset, что позволяет управлять младшими двумя байтами смещения назначения.

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

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

Целью служила x86-64 Ubuntu 16.04.2 с ядром 4.8.0-41-generic, KASLR, SMEP и SMAP. Все этапы выполняются внутри непривилегированного пространства имён пользователя.

Формирование кучи

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

packet_sock занимает около 1920 байт, поэтому использует кеш SLUB kmalloc-2048. В этом ядре Ubuntu кеш получает от buddy allocator slab размером 0x8000 байт. Последовательность формирования:

1. Создать около 512 пакетных сокетов, чтобы заполнить существующие slab kmalloc-2048.

2. Выделить 1024 блока кольца размером 0x8000, чтобы исчерпать freelist buddy allocator и заставить его разделять блоки.

3. Выделить кольцо из двух блоков размером 0x8000; его последний блок будет переполнен.

4. Создавать дополнительные пакетные сокеты, пока SLUB не выделит свежий slab непосредственно после этого блока кольца.

Точные количества зависят от активности машины, но на бездействующей системе Ubuntu эта схема работала.

Управление перезаписью

За границы копируется содержимое пакета. Необработанные пакеты, отправленные через loopback в изолированном сетевом пространстве имён, предоставляют произвольные данные без внешнего трафика. Пакеты должны иметь длину не менее 14 байт, младшие три бита nxt_offset из-за выравнивания всегда равны двум, а записываемые ядром заголовки кадров повреждают часть окружающих байтов.

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

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

Полезны два указателя функций в packet_sock:

• packet_sock->rx_ring->prb_bdqc->retire_blk_timer->func

• packet_sock->xmit

Таймер вывода блока предоставляет вызов func(data): обычно его функцией является prb_retire_rx_blk_timer_expired, а данные указывают на packet_sock. Перезапись обоих полей позволяет вызвать native_write_cr4 со значением, сбрасывающим биты 20 и 21 CR4, и отключить SMEP и SMAP на текущем CPU. sched_setaffinity удерживает последующее выполнение на этом ядре.

После разрешения выполнения из пользовательского пространства второе переполнение направляет xmit на пользовательскую полезную нагрузку, вызывающую commit_creds(prepare_kernel_cred(0)). Отправка через повреждённый сокет вызывает её в контексте процесса и предоставляет права root.

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

1. Определить адрес текста ядра.

2. Сформировать кучу.

3. Разместить packet_sock после блока кольца и запланировать его таймер вывода.

4. Переполнить таймер, чтобы он вызвал native_write_cr4 со сброшенными битами SMEP/SMAP.

5. Дождаться таймера на закреплённом CPU.

6. Сформировать ещё одну пару кольцо/сокет.

7. Переполнить xmit адресом пользовательской полезной нагрузки для изменения credentials.

8. Отправить пакет и получить root.

Исходный код эксплойта также очищает повреждённые поля вроде mclist, чтобы предотвратить последующие сбои.

Обход KASLR

Ubuntu по умолчанию не ограничивала dmesg. Строка ранней загрузки Freeing SMP alternatives memory раскрывала адрес с постоянным смещением относительно _text ядра:

Простое вычитание даёт slide. dmesg_restrict блокирует обычное чтение syslog, хотя первый пользователь Ubuntu часто входит в группу adm и может читать /var/log/kern.log. kptr_restrict не помогал, поскольку затронутый код версии 4.8 использовал %p, а не %pK. Linux 4.10 перестал выводить диапазон, но это изменение не было перенесено в старые ветки.

Исправление

Простое сравнение значений без приведения типа всё ещё допускает переполнение внутри BLK_PLUS_PRIV:

Окончательное исправление расширяет контролируемое атакующим значение до выполнения арифметики:

Меры защиты

Пакетные сокеты требуют CAP_NET_RAW, но непривилегированные пространства имён пользователя могут её предоставить. Системы могут перекрыть этот путь, собрав ядро без CONFIG_USER_NS или ограничив создание пространств имён. Ядра на основе Debian предоставляют /proc/sys/kernel/unprivileged_userns_clone; запись нуля запрещает непривилегированное создание. В upstream-ядрах начиная с версии 4.9 доступен /proc/sys/user/max_user_namespaces.

Заключение

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

Связанные материалы: эксплойт CVE-2017-7308, исправление upstream, syzkaller, KASAN, KTSAN и KMSAN.

В статье исследуются обе платформы, демонстрируется архитектурная проблема, позволяющая откатываться к старым уязвимым trustlet, эксплуатируется один из них и рассматриваются меры защиты от эксплуатации. Большинство устройств Qualcomm и все версии Kinibi до 400 оставались затронуты; среди устройств Samsung Exynos на момент публикации новую защиту от отката использовали только Galaxy S8 и S8 Plus.

TEE TrustZone

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

В обоих мирах существуют EL0 и EL1. Ядро Linux и приложения Android работают на обычных EL1 и EL0; доверенная ОС — на S-EL1, а trustlet — на S-EL0. EL2 не дублируется в Secure World.

QSEE и Kinibi предоставляют биометрические функции, привязанную к оборудованию криптографию, доверенные пользовательские интерфейсы и другие службы. Их тесная связь с оборудованием требует интеграции с загрузчиком. Normal World взаимодействует с ними через библиотеки, демоны и драйверы ядра производителя.

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

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

Trustonic открыто документирует MobiCore Loadable Format, также доступны загрузчики для IDA.

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

Отзыв в QSEE

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

Закрытый ключ последнего сертификата подписывает объединённые хеши. Корневой сертификат проверяется по хешу корневого ключа в ROM или однократно программируемых eFuse. Поля OU сертификата привязывают политику к подписи. SW_ID объединяет идентификатор образа и счётчик версии; значение eFuse выше версии образа должно запрещать откат.

Разбор сертификата Widevine устройства Pixel с помощью OpenSSL показал идентификатор образа 0xC и нулевую версию. Все trustlet имели один и тот же идентификатор образа.

Исследование более 45 образов прошивок Google, Samsung, LG, Motorola и других производителей обнаружило только один образ, где версия хотя бы одного trustlet была выше нуля. При этом известные уязвимости уже исправлялись, включая ошибку выполнения кода Widevine в Nexus 6. Исправленные устройства всё равно принимали старый уязвимый trustlet: атакующему было достаточно поместить его куда угодно и изменить один путь в исходном эксплойте.

QSEECOM получает буфер памяти, а не путь к файлу, поэтому драйвер ядра не может просто разрешить загрузку только из /system. Взаимодействовать с ним могут несколько привилегированных доменов SELinux, включая службы media, DRM, KeyStore, томов и отпечатков пальцев.

Некоторые устройства могут хранить версии отдельных приложений в защищённом от воспроизведения хранилище Replay Protected Memory Block. APP_ID позволяет точнее идентифицировать trustlet, но для этого требуется заранее настроенный eFuse. Несколько производителей повторно использовали один APP_ID для множества приложений, лишая отзыв точной гранулярности. Устройства с разблокируемым загрузчиком создают конфликт политик: необратимые счётчики отката мешают пользователям загружать законно выбранные старые прошивки.

Отзыв в Kinibi

Анализ Kinibi проводился на Galaxy S7 Edge с TEE 310B. Открытые заголовки MCLF описывают метаданные, код и данные, оставляя непрозрачный завершающий блок подписи.

Ядро TEE встроено как BL32 в Samsung SBOOT. Его можно найти, проследив процесс загрузки ARM Trusted Firmware; строка VERSION_-+A0 отмечает начало, а цели переходов вместе с VBAR указывают виртуальную базу 0x7F00000.

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

Проверяемого счётчика отката найти не удалось. Каждый trustlet в коллекции прошивок имел нулевую версию службы. mcDriverDaemon загружает trustlet из /system/app/mcRegistry или /data/app/mcRegistry; запрошенный UUID выбирает имя файла, но не сравнивается с UUID внутри бинарного файла. Старый trustlet отпечатков пальцев, помещённый в реестр данных под произвольным запрошенным UUID, успешно загрузился.

Unix-сокет демона и драйвер ядра доступны широкому кругу привилегированных процессов. Trustonic добавила предотвращение отката в Kinibi 400, используемой Galaxy S8/S8 Plus. На старых устройствах Exynos нет отдельного состояния, необходимого для отклонения старых подписанных образов.

Выбор цели

Сравнение исходной и текущей прошивок раскрывает исправления, относящиеся к безопасности. Galaxy S7 и S7 Edge также используют общий ключ подписи trustlet, поэтому подписанные trustlet каждого из устройств работают на другом. Быстрое сравнение trustlet CCM обнаружило четыре новые проверки границ.

Более простой целью оказался trustlet OTP от Samsung. Две тривиальные ошибки, найденные годом ранее, уже исправили, но старые подписанные образы по-прежнему можно было загружать.

Написание быстрого эксплойта

Приложение OTP генерирует токены с помощью ключей, привязанных к TrustZone. Его командный цикл диспетчеризует 32-битные идентификаторы команд из Normal World. Несколько команд вызывают otp_unwrap, передавая контролируемую пользователем длину токена без проверки. Функция копирует данные такой длины в буфер стека.

Слишком большой токен перезаписывает стек через кадры между otp_unwrap и process_cmd. Stack cookie на пути нет. Эксплойт заменяет сохранённый LR первым ROP-гаджетом и размещает цепочку в необычно больших промежуточных кадрах.

Цепочка подготавливает аргументы, вызывает произвольную функцию trustlet и возвращает результат в process_cmd. Гаджеты чтения и записи предоставляют доступ к памяти; службы ОС TEE вызываются через уже импортированные в trustlet функции. Оставшаяся часть стека заполняется sled из POP {PC} до последнего кадра, восстанавливающего несбрасываемое состояние.

Многие trustlet обходятся без кучи и полагаются на глобальные данные и огромные стеки, что увеличивает частоту переполнений стека. Без cookies такие ошибки эксплуатируются напрямую. Опубликованный эксплойт создаёт позиционно-независимый blob, подходящий для внедрения в привилегированный процесс вроде system_server.

Меры защиты

Сравнение проводилось между Kinibi 310B на Galaxy S7 Edge и QSEE на Nexus 6, с выполнением кода в одном trustlet каждой платформы.

ASLR

В Kinibi нет ASLR. Каждый trustlet загружается по фиксированному адресу из заголовка MCLF, обычно 0x1000, а общая вспомогательная библиотека mcLib всегда находится по адресу 0x7D01000. Поэтому и код приложения, и гаджеты системных вызовов/вызовов предсказуемы.

QSEE рандомизирует trustlet, но каждое виртуальное адресное пространство представляет собой плоское отображение в физически непрерывную выделенную область secapp, обычно размером около 100 Мбайт. Это ограничивает энтропию примерно девятью битами. Поскольку недействительный доступ лишь завершает перезагружаемый trustlet, практичен многократный подбор: около 355 попыток дают 50-процентную вероятность успеха.

Stack cookies и guard pages

В trustlet Kinibi не было stack cookies. QSEE использовала рандомизированные cookies размером с указатель. Ни одна платформа не размещала guard pages между глобальными данными, кучей и стеком; все области вырезались из одного сегмента данных. Поэтому переполнение любой области может достигнуть остальных.

TEE как особо ценная цель

Galaxy S8 поставлялся по меньшей мере с 30 trustlet, расширяя доверенную вычислительную базу и поверхность атаки. Выполнение кода особенно ценно, поскольку TEE хранит ключи шифрования KeyMaster, ключи расшифровки Widevine и биометрические идентификаторы.

В QSEE любой trustlet может отображать физическую память Normal World. Поэтому компрометация одного из них позволяет найти и изменить ядро Linux.

В Kinibi действует более строгая модель: trustlet запрашивают службы у драйверов, а драйверы могут задавать белые списки UUID вызывающих приложений. Но каждый драйвер способен обращаться к физической памяти, поэтому предоставляемые API необходимо проектировать осторожно. Драйвер TIMA от Samsung предоставляет физическое чтение и запись для измерения целостности и разрешает неожиданно большой набор trustlet, ослабляя задуманное разделение.

Послесловие

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

Поскольку TEE занимает привилегированное положение в оборудовании, её компрометация угрожает не только секретам, обрабатываемым в Secure World, но часто и безопасности всего устройства. Будущим системам необходимы надёжная защита от отката для каждого приложения, более строгая изоляция trustlet, современные меры защиты от повреждения памяти и узко ограниченные возможности драйверов.

Для демонстрации используются уязвимый учебный драйвер и модуль PowerShell NtObjectManager. Сам приём не является уязвимостью; это строительный блок для отдельного дефекта создания каталогов.

Краткие сведения о классе уязвимостей

Win32 разделяет CreateFile и CreateDirectory, но Native API использует для обеих операций ZwCreateFile. Флаги FILE_DIRECTORY_FILE и FILE_NON_DIRECTORY_FILE в CreateOptions выбирают ожидаемый тип объекта. Уязвимая вспомогательная функция драйвера может выглядеть так:

Важны три детали:

• FILE_DIRECTORY_FILE создаёт каталог.

• FILE_OPEN_IF создаёт его, если он отсутствует, либо открывает существующий.

• Вызов точки входа Zw из режима ядра обходит проверки доступа, если не установлен флаг OBJ_FORCE_ACCESS_CHECK.

Если код выполняется в контексте атакующего процесса, новый каталог принадлежит этому пользователю, который может изменить его дескриптор безопасности. Многие системные каталоги также предоставляют создателю права через ACE CREATOR OWNER.

Создание произвольного каталога

Учебный драйвер предоставляет устройство \Device\WorkshopDriver; управляющий код IOCTL 2 передаёт непроверенную строку UNICODE_STRING в уязвимую вспомогательную функцию. PowerShell может вызвать её следующим образом:

Каталог C:\Windows\abc успешно создаётся, а его ACL подтверждает, что он принадлежит непривилегированной учётной записи.

Злоупотребление точкой подключения

В соединении NTFS хранится атрибут $REPARSE_POINT, содержащий альтернативный путь Native Object Manager. Этот путь не обязан указывать на каталог: он может вести к файлу.

Win32 отклоняет такое соединение. Нативное открытие с заданным флагом типа даёт парадоксальные результаты: при открытии как файла сообщается о каталоге, а при открытии как каталога — о файле. Если не указан ни FILE_DIRECTORY_FILE, ни FILE_NON_DIRECTORY_FILE, NTFS успешно переходит по точке подключения к файлу.

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

Поддержка национальных языков

Windows отображает данные кодовых страниц через системный вызов NtGetNlsSectionPtr. Его упрощённая реализация выглядит так:

Сначала функция ищет постоянную секцию в \NLS, где кодовые страницы имеют имена NlsSectionCP<NUM>.

Если секция отсутствует, функция формирует имя файла:

Эта функция полезна благодаря двум свойствам:

• Флаг OBJ_FORCE_ACCESS_CHECK отсутствует, поэтому ZwOpenFile режима ядра может открыть недоступные файлы.

• Значение CreateOptions равно нулю, поэтому функция переходит по точке подключения каталога к файлу.

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

Эксплойт создаёт \SystemRoot\System32\c_1337.nls, превращает его в точку подключения, направленную на \SystemRoot\System32\config\SAM, запрашивает кодовую страницу 1337 и копирует возвращённое отображение:

Скопированный файл представляет собой действительный куст SAM.

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

Итоги

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

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

Исторически движки DOM были одним из основных источников браузерных уязвимостей. Целевые атаки всё чаще предпочитали Flash и движки JavaScript, но ошибки DOM оставались распространёнными: CVE-2016-9079, применявшаяся против пользователей Tor Browser в ноябре 2016 года, была связанной с SVG ошибкой DOM в Firefox. Обновления безопасности браузеров также продолжали содержать многочисленные исправления DOM.

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

Фаззер

Новый фаззер под названием Domato учитывал уроки предыдущих DOM-фаззеров, стремясь при этом к понятному расширяемому коду и возможности применения не только к DOM. Это генеративный фаззер: грамматики описывают структуру HTML и CSS, а также объекты, свойства и методы JavaScript, после чего движок строит каждый образец с нуля.

Domato состоит из:

• универсального движка генерации на основе грамматик;

• основного сценария со специальной логикой управления DOM;

• грамматик HTML, CSS и JavaScript.

Исходные объявления были получены из файлов .idl Chrome, а имена и значения свойств HTML и CSS — из тестов компоновки. Затем автоматически извлечённые данные подверглись значительной ручной обработке. Например, параметр, принимающий строку, редко ведёт себя интересно при каждой произвольной строке.

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

Конфигурация

В эксперименте Chrome, Firefox, Internet Explorer, Edge и Safari/WebKit прошли примерно по 100 миллионов итераций. Более длинные кампании обрезались до ошибок, найденных в пределах общего бюджета. При десяти секундах на запуск решительный атакующий мог провести такую кампанию примерно за 1 000 долларов на небольших прерываемых виртуальных машинах Google Compute Engine.

• Chrome запускался во внутренней службе Google ClusterFuzz на нескольких сборках.

• Для Firefox использовались загружаемые ASAN-сборки Mozilla для Linux; сбои воспроизводились на выпущенных версиях.

• Internet Explorer 11 запускался в Windows Server 2012 R2 в Google Compute Engine с включённой страничной кучей для iexplore.exe.

• Для Edge потребовался кластер Windows 10 в Microsoft Azure; страничная куча включалась для MicrosoftEdgeCP.exe.

• Safari представляла выпущенная ASAN-сборка WebKitGTK+ для Linux, а каждый сбой проверялся на ночной ASAN-сборке WebKit на Mac.

Результаты

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

Сумма по строкам равна 33, поскольку две ошибки затрагивали несколько браузеров. Одна проблема Firefox находилась в Skia, а не в исходном коде Mozilla, но соответствующий код был предоставлен инженерами Mozilla. Все перечисленные ошибки исправлены в выпущенных версиях.

Большинство браузеров показало хорошие результаты по сравнению с аналогичным тестированием несколькими годами ранее. Различия между Chrome, Firefox, IE и Edge не были статистически достаточными для ранжирования их DOM-движков. Safari явно выделялся 17 ошибками. Это вызывало беспокойство с учётом интереса атакующих к платформам Apple и было примечательно, поскольку всего несколькими годами ранее Chrome и Safari использовали общий WebKit. Apple получила фаззер и описание методики для внутреннего улучшения WebKit.

Internet Explorer и Edge также продемонстрировали эффект MemGC. Его отключение через OverrideMemoryProtectionSetting выявило намного больше ошибок использования после освобождения, но Microsoft считала эти проблемы надёжно нейтрализованными, и я согласен с такой оценкой. MemGC явно сократил в реальных условиях класс ошибок, некогда доминировавший в IE.

Результаты относятся только к движкам DOM. Они не измеряют качество песочницы, движков JavaScript или других компонентов браузера. Кроме того, фаззер может лучше находить одни типы ошибок DOM, чем другие.

Эксперимент с DOM-фаззингом, управляемым покрытием

Экспериментальный вариант объединил мутации Domato с изменённым клиентом DynamoRIO для WinAFL и был нацелен на mshtml.dll в Internet Explorer. Цикл выглядел так:

1. Изменить образцы корпуса.

2. Запустить IE со страницей испытательного стенда.

3. Начать сбор покрытия и загрузить образец в iframe.

4. Остановить сбор после завершения выполнения.

5. Добавить образцы, открывшие новое покрытие.

6. Продолжать до выполнения всех образцов или сбоя IE.

7. Периодически минимизировать корпус с помощью AFL cmin.

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

Заключение

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

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