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

Проблема 1267, раскрытие в win32k!NtGdiGetGlyphOutline, затрагивала Windows 7 и 8, но уже была тихо исправлена в Windows 10. Diaphora показала очевидный новый вызов обнуления.

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

• прямой вызов memset;

• встроенная инструкция rep stosd;

• развёрнутая последовательность инструкций mov, записывающих нули.

Hex-Rays декомпилирует прямой вызов и rep stosd как обычный memset, упрощая сравнение.

Короткие последовательности mov не распознавались, но встречались достаточно редко для ручной проверки. Процесс запускался отдельно для Windows 7 против 10 и Windows 8.1 против 10:

1. Декомпилировать ntkrnlpa.exe и win32k.sys Windows 7/8.1, а также ntoskrnl.exe, tm.sys, win32kbase.sys и win32kfull.sys Windows 10.

2. Извлечь отсортированные списки функций с memset, сохранив число вызовов.

3. Текстово сравнить списки и оставить функции с большим количеством обнулений в Windows 10.

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

Ручная проверка кандидатов выявила ещё две уязвимости.

win32k!NtGdiGetFontResourceInfoInternalW (CVE-2017-8684)

Windows 10 добавила новый memset в этот обработчик.

Ошибка раскрывала около 0x5c (92) байт стека ядра. Для выходных данных не больше 92 байт системный вызов использует локальный стековый буфер, для более крупных запросов — PALLOCMEM.

PALLOCMEM уже очищает выделения пула, поэтому утекала только короткая ветка стека.

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

1. Выделить временный буфер запрошенного пользователем размера.

2. Попросить GetFontResourceInfoInternalW заполнить нужные сведения.

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

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

win32k!NtGdiEngCreatePalette (CVE-2017-8685)

Эта ошибка была исправлена обнулением в Windows 8, тогда как Windows 7 оставалась уязвимой.

Системный вызов создаёт палитру GDI из N четырёхбайтовых цветов. Для не более 256 записей используется стековый массив 1024 байта и bSafeReadBits; более крупные массивы блокируются непосредственно в пользовательской памяти.

bSafeReadBits сообщает об успехе, ничего не копируя, если любой из указателей равен NULL.

Указатель источника поступает непосредственно из третьего аргумента системного вызова. Передача NULL оставляет весь локальный массив нетронутым, хотя вызывающий считает, что получил 256 записей:

Возвращённая палитра хранит эти неинициализированные байты стека. GetPaletteEntries читает весь 1 КиБ обратно в процесс атакующего.

Windows 8.1 вручную очищает первый DWORD и вызывает memset для оставшихся 0x3FC байт; Windows 10 очищает все 0x400 одним вызовом.

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

Выводы

Различия безопасности поддерживаемых веток раскрывают слабости и векторы атаки старых продуктов. Этот анализ фактически был текстовым сравнением псевдокода и не требовал глубоких низкоуровневых знаний. При умеренных усилиях он выявил CVE-2017-8680, CVE-2017-8684 и CVE-2017-8685.

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

Независимые исследователи описали варианты 1 и 2 в работе 2018-01-03-spectre.pdf (файл в files/2018-01-03-spectre.pdf), а вариант 3 — в 2018-01-03-meltdown.pdf (файл в files/2018-01-03-meltdown.pdf). Доказательства концепции Project Zero продемонстрировали утечку внутри одного процесса на Intel, AMD и Cortex-A57; чтение ядра Linux через eBPF со скоростью около 2000 байт/с; чтение ядра хоста KVM из гостевой системы со скоростью около 1500 байт/с; чтение ядра вариантом 3 при определённых предварительных состояниях кеша.

Проверенные процессоры

• Intel Xeon E5-1650 v3, Haswell.

• AMD FX-8320.

• AMD PRO A8-9600.

• ARM Cortex-A57 в Nexus 5X.

Термины

Завершение архитектурно фиксирует результаты инструкций. ЦП может выполнять инструкции не по порядку, но завершает их по порядку.

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

Окно ошибочной спекуляции — интервал до того, как ЦП обнаружит неверное предсказание и перенаправит выполнение.

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

Вариант 1: обход проверки границ Теоретическое объяснение

Рассмотрим обычную проверку границ:

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

После отката измерение времени доступа к arr2[0x200] и arr2[0x300] раскрывает один секретный бит. Повторение позволяет получить произвольные данные.

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

Атака на ядро

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

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

Вместо побайтового сканирования процесс отображает одни и те же 16 физических страниц в 32 768 соседних виртуальных диапазонов, покрывая 2 ГиБ. Спекулятивное обращение к любому псевдониму кеширует его общую физическую страницу, позволяя делать большие шаги по адресам.

Попадание раскрывает старшие и младшие биты адреса; повторное деление пополам с двумя общими страницами восстанавливает средние биты.

Вторая программа eBPF читает выбранное во время выполнения значение за пределами victim_map, выделяет один бит и использует его для выбора двух смещений prog_map, разделённых 128 байтами:

Измерение времени псевдонимных страниц пользовательского пространства раскрывает бит. На проверенном Haswell это работало как с включённым, так и с отключённым JIT eBPF; на AMD PRO требовался JIT.

Вариант 2: внедрение цели перехода Основы

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

Внутреннее устройство предсказания переходов Haswell

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

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

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

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

Чтение памяти хоста из гостевой системы KVM

Доказательство концепции выполнялось с правами root в гостевой системе KVM против определённого ядра хоста Debian. Инициализация занимала 10–30 минут на хосте с 64 ГиБ памяти; затем скорость утечки достигала примерно 1500 байт/с.

Процесс:

1. Находит ядро хоста с помощью отпечатков истории переходов и известного кода KVM.

2. Определяет наборы кеша хоста и вытесняет выбранные данные жертвы.

3. Находит виртуальный адрес хоста, соответствующий управляемой гостевой странице.

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

5. Кодирует память хоста в состояние кеша и измеряет доступные гостю псевдонимы.

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

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

Вариант 3: несанкционированная загрузка кеша данных

Вариант 3 позволяет временно загрузить данные с привилегированного виртуального адреса до того, как ЦП завершит проверку разрешений. Архитектурная инструкция, вызывающая ошибку, никогда не завершается, но зависимая пробная загрузка записывает секрет в кеш. Доказательство концепции читало память ядра Haswell, когда целевые данные находились в L1D.

Это механизм, независимо получивший название Meltdown. Отделение таблиц страниц ядра от пользовательских процессов, как в 2018-01-03-kaiser.pdf (файл в files/2018-01-03-kaiser.pdf), удаляет большинство привилегированных отображений и блокирует прямой вариант между пользователем и ядром.

Идеи для дальнейших исследований

Среди возможных направлений:

• Побочные каналы, отличные от измерения времени кеша данных.

• Поведение предсказателей на других микроархитектурах.

• Эксплуатируемые шаблоны, создаваемые дополнительными JIT-движками.

• Более быстрый поиск адресов хоста и наборов кеша.

• Полное извлечение состояния BTB/BHB.

• Более качественные гаджеты варианта 2 и утечка нескольких битов.

• Отравление предсказателя возвратов и спекулятивное раскрытие стека возвратов.

• Скрытые каналы через сам предсказатель косвенных вызовов.

Заявления производителей

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

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

Полные результаты доступны в техническом отчёте о JIT-сервере. Связанные с ним инструменты и демонстрационный код опубликованы в репозитории инструментов Project Zero.

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

SwiftShader — программная реализация OpenGL ES и Direct3D 9, которую Chrome использует как резервный модуль отрисовки. При масштабировании исходной текстуры в более крупную область назначения позиции в источнике вычисляются с дробным шагом. В резервном цикле копирования применялось последовательное сложение:

Границы уже были проверены в предположении, что каждая точка (x,y) останется внутри sRect. Независимое вычисление xStart + i*w ограничило бы каждую ошибку округления. При повторении x += w ошибка распространяется на тысячи пикселей.

Chrome ограничивал размеры текстуры значением 8192, поэтому все чётные соотношения размеров источника и назначения можно было перебрать. Наибольшее расхождение давали ширина источника 5828 и ширина назначения 8132. У последних пикселей последовательные и прямые вычисления выглядели так:

Результат прямого вычисления остаётся внутри источника; последовательное сложение после преобразования в целое число выходит за границы и читает целую строку за пределами текстуры. WebGL может вернуть эти пиксели JavaScript, что приводит к раскрытию информации. Такой же дефект присутствовал в пути JIT-компиляции LLVM библиотеки SwiftShader.

Skia

Skia отрисовывает содержимое Chrome, Firefox, Android, Canvas 2D, SVG и других систем. Особенно сложны контуры, содержащие линии, квадратичные кривые и кубические сплайны.

Отсечение каждого пикселя требует больших ресурсов. Сначала Skia вычисляет границы объекта:

• Полностью снаружи: ничего не рисовать.

• Частично внутри: включить блиттер с отсечением.

• Полностью внутри: рисовать напрямую без попиксельных проверок.

Если последующая арифметика координат отличается от расчёта границ, третий путь выполняет запись за пределами изображения. hair_path добавляет запас безопасности в один или два пикселя. SkScan::FillPath использует kConservativeRoundBias и SkScanClipper.

В Skia смешиваются три формата:

• SkScalar: 32-разрядное число с плавающей точкой.

• SkFDot6: знаковое число с фиксированной точкой, 26 разрядами целой и 6 разрядами дробной части.

• SkFixed: знаковое число с фиксированной точкой формата 16.16.

Расхождение при преобразовании целого числа в число с плавающей точкой

Нижняя граница на уровне контура вычислялась так:

Значения больше -0.5, например -0.499, округляются до нуля и проходят отсечение. SkEdge::setLine выполняла преобразование через SkScalarRoundToFDot6 и получала -32, то есть ровно -0.5 — меньшее значение.

Умножение дробей

SkFixedMul умножает значения 16.16, а затем сдвигает результат вправо:

При умножении -1/2^16 на 1/2^16 должно получиться -1/2^32, но арифметический сдвиг вправо даёт 0xFFFFFFFF, то есть -1/2^16. Эта значительно большая отрицательная поправка может сдвинуть линию ещё на 1/64 пикселя влево. В сочетании с расхождением преобразования Skia растеризует x = -1, приняв контур за находящийся в границах. SVG в Firefox мог вызвать эту запись за пределами памяти.

Аппроксимация сплайна с плавающей точкой

hair_cubic вычисляет коэффициенты кубической кривой последовательно не более чем для 512 отрезков:

Даже если все четыре контрольные точки находятся внутри консервативно проверенного интервала, округление коэффициентов и повторение t += dt могут вывести промежуточную точку линии за их пределы. Для поверхности размером 32767 пикселей при допустимом максимуме 32766 получались точки 32766.003906 и 32766.015625.

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

Аппроксимация сплайна с фиксированной точкой

Эксплуатируемая актуальная проблема находилась в SkCubicEdge::setCubicWithoutUpdate. Функция преобразует точки в SkFDot6, а затем вычисляет производные с фиксированной точкой:

Для x0=-30, x1=x2=x3=-31 в формате 26.6 и сдвигов на шесть разрядов D=-64. Математическое деление на 4096 даёт крошечную отрицательную дробь; арифметический сдвиг даёт -1, делая производную слишком отрицательной. Повторные обновления сегментов перемещают последующие точки за минимальную контрольную точку. Затем ещё одно преобразование с фиксированной точкой пересекает значение -0.5, и растеризация происходит при x=-1.

В растровом изображении с построчным расположением точка x=-1 обычно попадает в предыдущую строку, а не за пределы выделенной памяти. SVG с атрибутом shape-rendering="crispEdges" явно рисует красные пиксели у правого края, хотя все координаты контура находятся слева.

(картинка не сохранилась в архиве)

Добавление linearGradient выбирает SkARGB32_Shader_Blitter, который выделяет временный буфер шириной ровно в одну строку. При рисовании от x=-1 до width-1 в него записывается width+1 пикселей, и визуальная ошибка точности превращается в переполнение буфера кучи. Были затронуты и Chrome, и Firefox; в Firefox артефакт было проще продемонстрировать, поскольку Chrome применяет дополнительное разбиение на фрагменты.

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

Заключение

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

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

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

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

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

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

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

Пример: CVE-2018-10751

CVE-2018-10751 представляла собой удалённо активируемое повреждение памяти OMACP в Galaxy S7 Edge. Для срабатывания без взаимодействия с пользователем было достаточно одного SMS, а обычное приложение Android могло отправить полезную нагрузку без root-доступа или специального оборудования.

Документированный процесс Samsung

На странице Samsung Mobile Security Reporting была кнопка создания отчёта.

Если учётной записи Samsung не было, регистрация неожиданно открывала корейскую страницу.

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

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

Наконец становилась доступна форма отчёта об уязвимости.

В конце находилось ещё одно обязательное соглашение.

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

Выявленные проблемы

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

У Android была похожая проблема: веб-форма требовала учётную запись Google, создание которой могло включать множество экранов и подтверждение по SMS. После отзывов Android указала security@android.com как альтернативный адрес электронной почты, сохранив форму для участия в программе вознаграждений.

Привязка всех отчётов к соглашениям программы вознаграждений встречается всё чаще. Процесс Cloudflare для срочного раскрытия CloudBleed указывал только на HackerOne. 90-дневная политика Project Zero отличалась от 180-дневной политики HackerOne, а пользовательские данные активно утекали, однако перед использованием объявленного пути команде пришлось бы изучить условия платформы.

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

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

Регистрация ошибки

Существующие контакты в команде Knox Samsung посоветовали адрес mobile.security@samsung.com, отсутствовавший на действующей странице и упоминавшийся только в статье 2015 года. Поиск этого пути задержал серьёзный отчёт на неделю, а без прежних контактов мог занять ещё больше времени.

Samsung назначила идентификатор SVE-2018-11463 и начала распространять исправление в апрельском техническом выпуске.

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

Заключение

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

• регулярно испытывать каждый интерфейс отчётов извне корпоративной сети и на всех поддерживаемых языках;

• свести к минимуму число переходов, объём обязательных личных данных и посторонние юридические соглашения;

• разрешать сообщения об уязвимостях без обязательного участия в программе вознаграждений;

• быстро подтверждать получение;

• публиковать резервный адрес электронной почты и запрашивать отзывы вероятных авторов отчётов.

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

Создание приложений Desktop Bridge выполняется в AppInfo. Служба вызывает недокументированную CreateAppContainerToken, не олицетворяя пользователя. При настройке токена API создаёт под пользовательским пространством AppContainerNamedObjects каталоги для BaseNamedObjects и перенаправления конечных точек RPC. Поскольку AppInfo остаётся SYSTEM, каталоги создаются от имени SYSTEM.

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

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

Эксплуатация Почему важен KnownDlls

В \KnownDlls находятся именованные секции образов вроде NAME.DLL. При загрузке DLL из System32 загрузчик сначала проверяет это пространство имён и только затем создаёт секцию образа из файла.

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

DefineDosDevice и CSRSS

Win32 API DefineDosDevice обычно создаёт символическую ссылку буквы диска в пользовательском каталоге DOS-устройств вызывающего. Реализация выполняет RPC-вызов BaseSrvDefineDosDevice в CSRSS сеанса, позволяя службе делать ссылки постоянными с помощью SeCreatePermanentPrivilege.

API не требует имени буквы диска. Значение вроде GLOBALROOT\RPC Control\ABC дополняется префиксом \??\ и может выйти в произвольный путь диспетчера объектов через специальную ссылку GLOBALROOT.

Упрощённая логика сервера:

IsGlobalSymbolicLink лишь проверяет, начинается ли разрешённое имя открытого объекта с \GLOBAL??\. Если да, CSRSS отключает олицетворение и заново создаёт ссылку от имени SYSTEM. Обычно удалить глобальную ссылку может только администратор. Проблема 1550 создаёт доступный пользователю дочерний каталог под \GLOBAL??, из-за чего находящаяся внутри ссылка одновременно доступна пользователю для удаления и выглядит глобальной.

Переписывание пути в KnownDlls

Эксплойт использует разницу между исходным префиксом \?? и префиксом повторного создания \GLOBAL??:

1. Через проблему 1550 создать доступный пользователю каталог \GLOBAL??\KnownDlls.

2. В нём создать ссылку TAPI32.DLL с любой целью.

3. В пользовательском каталоге DOS-устройств создать GLOBALROOT, указывающий на \GLOBAL??, и тем самым затенить настоящую глобальную ссылку при первом поиске.

4. Вызвать DefineDosDevice для GLOBALROOT\KnownDlls\TAPI32.DLL, указав пространство назначения, доступное атакующему для записи.

5. Сначала CSRSS откроет \??\GLOBALROOT\KnownDlls\TAPI32.DLL, который через пользовательскую тень разрешится в \GLOBAL??\KnownDlls\TAPI32.DLL.

6. IsGlobalSymbolicLink вернёт true, поэтому олицетворение отключится.

7. CSRSS построит \GLOBAL??\GLOBALROOT\KnownDlls\TAPI32.DLL. Теперь будет пройдена настоящая GLOBALROOT, в результате чего от имени SYSTEM получится \KnownDlls\TAPI32.DLL.

8. Создать контролируемую атакующим секцию образа в цели ссылки.

9. Заставить привилегированную службу загрузить TAPI32.DLL; загрузчик отобразит вредоносную секцию KnownDlls.

Описанный ранее примитив DiagHub может активировать загрузку и дать выполнение LocalSystem.

Обход Protected Process Light

Тот же примитив внедряется в PPL. Windows назначает KnownDlls метку доверия процесса, обычно разрешающую запись только высшему уровню PPL.

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

Итоги

Microsoft исправила проблему 1550 в июне 2018 года, добавив CreateAppContainerTokenForUser, которая олицетворяет переданного пользователя при создании токена и пространства имён. Существующих пользователей старой CreateAppContainerToken всё ещё стоит проверить на уязвимый шаблон.

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

Для написания кода WebAssembly доступно несколько инструментов. Важная цель создателей формата — возможность компилировать C и C++ в WebAssembly, и соответствующие компиляторы уже существуют. Вероятно, в будущем в WebAssembly будут компилироваться и другие языки. Также код можно писать в текстовом формате WebAssembly, который напрямую представляет бинарный формат WebAssembly, итоговый формат любого кода WebAssembly.

Модули WebAssembly

Код в бинарном формате WebAssembly изначально находится в ArrayBuffer или TypedArray в JavaScript. Затем он загружается в модуль WebAssembly.

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

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

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

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

Начнём с CVE-2018-4222, которая возникает при чтении бинарного WebAssembly из содержащего его буфера. Объекты TypedArray в JavaScript могут задавать смещение доступа к лежащему в их основе ArrayBuffer. Реализация WebKit дважды прибавляла это смещение к указателю данных ArrayBuffer. Поэтому следующий код:

в неисправленной версии WebKit читает память за границами. Это также функциональная ошибка: из-за неё WebAssembly не может правильно обработать ни один TypedArray со смещением.

CVE-2018-6092 в Chrome — пример ошибки, возникающей при разборе буфера WebAssembly. В прошлом уже исправлялись похожие ошибки этого типа. В данной уязвимости целочисленное переполнение происходит при разборе локальных переменных функции из секции кода бинарного файла. Количество локальных переменных каждого типа суммируется, и содержащий результат size_t может переполниться на 32-битной платформе.

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

CVE-2018-4121 — ошибка проверки порядка секций в WebKit. В неисправленных версиях WebKit состояние проверки порядка сбрасывается после обработки пользовательской секции, фактически позволяя секциям встречаться сколько угодно раз и в любом порядке. Это приводит к переполнению нескольких векторов WebKit: реализация разбора выделяет память, предполагая наличие только одной секции каждого типа, а затем добавляет элементы без проверки. Даже без этой особенности реализации ошибка, вероятно, приводила бы ко множеству тонких повреждений памяти в движке WebAssembly, поскольку порядок и отсутствие дубликатов бинарных секций фундаментальны для работы WebAssembly.

Эту уязвимость независимо обнаружили Alex Plaskett, Fabian Beterke и Georgi Geshev из MWR Labs; описание их эксплойта доступно здесь.

Экземпляры WebAssembly

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

У каждого модуля есть загруженная из бинарного WebAssembly секция Imports. Она содержит имена и типы объектов, которые необходимо импортировать из JavaScript для выполнения кода модуля. Импортировать можно четыре типа объектов. Функции JavaScript или WebAssembly можно импортировать и вызывать из WebAssembly. Числовые типы также импортируются из JavaScript для заполнения глобальных значений.

Два оставшихся типа — объекты Memory и Table. Эти новые типы были добавлены в движки JavaScript для WebAssembly. Объекты Memory содержат память, используемую кодом WebAssembly. В JavaScript к ней обращаются через ArrayBuffer, а в WebAssembly — инструкциями load и store. При создании Memory разработчик WebAssembly задаёт начальный и необязательный максимальный размер памяти. Объект создаётся с выделенным начальным объёмом, который можно увеличить в JavaScript методом grow и в WebAssembly инструкцией grow. Размер памяти никогда не уменьшается, по крайней мере согласно стандарту.

Объекты Table представляют таблицы функций WebAssembly. В определённых индексах они содержат объекты функций, вызываемые из WebAssembly инструкцией call_indirect. Как и память, таблицы имеют начальный и необязательный максимальный размер; их можно расширить вызовом grow в JavaScript. Из WebAssembly расширять Table нельзя. Такие объекты могут содержать только функции WebAssembly, а не JavaScript; попытка добавить функцию неверного типа вызывает исключение. Сейчас WebAssembly поддерживает только по одному объекту Memory и Table на экземпляр. Вероятно, в будущем это изменится.

Несколько экземпляров могут совместно использовать один объект Memory и Table. Если два или более экземпляра разделяют оба объекта, считается, что они находятся в одном compartment. Можно создать экземпляры, разделяющие Table, но не Memory, или наоборот, однако ни один компилятор не должен создавать экземпляры с таким свойством. Ни один компилятор не меняет значения в таблице после инициализации, и, вероятно, это останется справедливым, но вызывающий JavaScript всё равно может изменить их в любой момент.

Добавить объекты Memory и Table в экземпляр можно двумя способами. Первый — через упомянутую секцию Imports. Второй — включить в бинарный файл секцию Memory или Table. Тогда движок WebAssembly создаёт для модуля необходимый объект с заданными в бинарном файле параметрами. Нельзя одновременно указывать объект и в Imports, и в Table или Memory: это означало бы наличие более одного объекта каждого типа, что сейчас запрещено. Memory и Table необязательны, и код WebAssembly довольно часто не имеет Table. Можно создать код и без Memory, например функцию, усредняющую переданные параметры, но на практике это встречается редко.

Возможность увеличивать размер выделенного объекта Memory или Table привела к нескольким уязвимостям. Например, CVE-2018-5093 — серия целочисленных переполнений при увеличении объектов Memory и Table, недавно обнаруженная OSS-Fuzz. Похожую ошибку OSS-Fuzz нашёл в Chrome.

Другой очевидный вопрос об объектах Memory — можно ли отсоединить внутренний ArrayBuffer, поскольку с его отсоединением связано множество уязвимостей. Согласно спецификации, скрипт не может отсоединить ArrayBuffer объекта Memory, и это верно во всех браузерах, кроме Microsoft Edge: Chakra запрещает операцию, но Edge её допускает. ArrayBuffer объекта Memory также не меняет размер при расширении Memory. Вместо этого он отсоединяется сразу после вызова метода grow. Так предотвращаются ошибки, которые могли бы возникнуть из-за изменения размера ArrayBuffer.

Доступ за границами всегда вызывает опасения, когда скрипту разрешают работать с памятью, но в WebAssembly такие ошибки довольно редки. Вероятная причина — ограниченное число инструкций WebAssembly, обращающихся к памяти, и текущая поддержка лишь одной страницы памяти, поэтому соответствующий код движка WebAssembly весьма мал. Кроме того, на 64-битных системах WebAssembly реализует память как безопасные буферы, также называемые signal buffers. Чтобы понять их работу, необходимо разобраться в load и store WebAssembly. Эти инструкции имеют два операнда: адрес и смещение. При обращении к памяти оба прибавляются к указателю начала внутренней памяти объекта Memory, и получившийся адрес становится целью операции. Оба операнда являются 32-битными целыми числами, хотя в будущих версиях WebAssembly это, вероятно, изменится, и должны быть больше нуля. Поэтому обращение может находиться не более чем на 0xfffffffe, то есть 4 Гбайт, за пределами выделенного буфера.

Безопасные буферы отображают в адресное пространство 4 Гбайт, после чего фактически нужная коду WebAssembly часть выделяется как память RW в начале отображённого диапазона. Обращения могут находиться не более чем в 4 Гбайт от начала буфера, поэтому все они должны попадать в этот диапазон. Если происходит обращение за пределами выделенной памяти, возникает сигнал или эквивалентная ошибка ОС. Движок WebAssembly обрабатывает её и выбрасывает в JavaScript соответствующее исключение выхода за границы. Безопасные буферы устраняют необходимость проверять границы в коде и снижают вероятность уязвимостей из-за доступа за пределами на 64-битных системах. На 32-битных системах явные проверки по-прежнему необходимы, но такие системы встречаются всё реже.

После загрузки импортированных объектов движок WebAssembly выполняет ещё несколько этапов создания экземпляра. Секция Elements бинарного WebAssembly инициализирует объект Table, если существуют оба; затем секция Data инициализирует Memory, если существуют оба. Потом код модуля используется для создания функций, которые экспортируются, то есть присоединяются к объекту JavaScript и становятся доступны из JavaScript. Наконец, если секция Start задаёт стартовую функцию, она выполняется, после чего WebAssembly готов к работе!

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

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

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

Выполнение

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

Будущее

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

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

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

(Оговорка: мы не исследовали, что происходит с данными рабочего профиля, когда пользователь с таким профилем отключает его.)

Упоминаемые в статье отчёты об ошибках и соответствующий демонстрационный код доступны по адресам:

• Проблема 1583: обход каталогов через USB посредством инъекции в вывод blkid

• Проблема 1590: повышение привилегий zygote→init; цепочка через USB

Проблемы были исправлены как CVE-2018-9445 на уровне исправлений 2018-08-01 и CVE-2018-9488 на уровне 2018-09-01.

Многие Android-телефоны поддерживают режим USB host, часто через адаптер OTG. Это позволяет подключать к ним разные USB-устройства; список необязательно полон:

• USB-накопители: после подключения накопителя к Android-телефону пользователь может копировать файлы между системой и устройством. Даже если телефон заблокирован, версии Android до P всё равно пытаются смонтировать накопитель. В Android 9, выпущенной после сообщения об этих ошибках, в vold появилась логика, запрещающая монтирование USB-накопителей при заблокированном устройстве.

• USB-клавиатуры и мыши: Android позволяет использовать внешние устройства ввода вместо сенсорного экрана. Это работает и на экране блокировки, например для ввода PIN.

• USB Ethernet-адаптеры: при подключении адаптера телефон пытается войти в проводную сеть, получая IP-адрес по DHCP. Это также работает на заблокированном телефоне.

Статья посвящена USB-накопителям. Монтирование недоверенного накопителя открывает нетривиальную поверхность атаки в высокопривилегированных системных компонентах. Ядро должно общаться с USB mass storage по протоколу, включающему подмножество SCSI, разбирать таблицу разделов и интерпретировать содержимое через реализацию файловой системы ядра. Код пользовательского пространства должен определить тип файловой системы и приказать ядру смонтировать устройство в выбранное место. В Android эта логика в основном находится в vold, одном из процессов с привилегиями, эквивалентными ядру. Для определения типов файловых систем разделов USB-накопителя он использует отдельные процессы в ограниченных доменах SELinux.

После подключения накопителя и определения списка его разделов vold пытается установить для каждого три свойства: Label, понятное пользователю описание; UUID, уникальный идентификатор, позволяющий узнать ранее подключавшийся накопитель; и тип файловой системы. В современной схеме GPT эти свойства в основном можно хранить в самой таблице разделов. Однако USB-накопители чаще используют MBR, которая не поддерживает UUID и метки. Для обычных накопителей Android поддерживает обе схемы.

Чтобы дать разделам метки и UUID даже при MBR, файловые системы используют обходной приём: их заголовок содержит поля этих атрибутов. Реализация, уже определившая тип файловой системы и знающая структуру её заголовка, извлекает значения специфичным для неё способом. Когда vold нужны label, UUID и тип, он запускает /system/bin/blkid в домене SELinux blkid_untrusted. Программа сначала определяет тип по magic numbers или, если не получилось, эвристикам, затем извлекает label и UUID. Результат выводится в stdout в формате:

Однако версия blkid в Android не экранировала строку label, а код разбора вывода blkid искал только первые вхождения UUID=" и TYPE=". Поэтому специально сформированная метка раздела позволяла управлять строками UUID и type, возвращаемыми vold, хотя в норме это всегда действительный UUID и один из фиксированного набора типов.

Когда vold определяет, что новый USB-накопитель с таблицей MBR содержит раздел vfat, который должна суметь смонтировать реализация vfat ядра, PublicVolume::doMount() строит путь монтирования по UUID файловой системы, обеспечивает существование каталога mountpoint с правильными владельцем и режимом, а затем пытается смонтировать поверх него:

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

Например, если вставить в заблокированный телефон накопитель с FAT, чья label равна ' UUID="../##', устройство смонтирует его в /mnt/##.

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

• Длина label: метка FAT ограничена 11 байтами. Для простой атаки шесть байтов ' UUID="' уходят на начало инъекции, оставляя лишь пять символов для traversal, чего недостаточно для интересной точки иерархии. Следующий раздел описывает обход.

• Ограничения SELinux на mountpoint: хотя vold считается эквивалентным ядру, политика SELinux ограничивает действия vold. В частности, разрешение mounton доступно только для набора допустимых labels.

• Требование доступности для записи: fs_prepare_dir() завершается ошибкой, если целевой каталог имеет режим не 0700 и chmod() не срабатывает.

• Ограничение доступа к vfat: при монтировании vfat все файлы получают label u:object_r:vfat:s0. Даже если файловая система смонтирована там, откуда загружается важный код или данные, многим контекстам SELinux запрещено с ней взаимодействовать; например, это запрещено zygote и system_server. Кроме того, процессы без привилегий обхода DAC должны входить в группу media_rw. Раздел «Работа с SELinux: двойная активация ошибки» объясняет, как обойти ограничения в контексте этой конкретной уязвимости.

Как описано выше, label FAT ограничена 11 байтами. blkid поддерживает другие файловые системы со значительно более длинными labels, но тогда пришлось бы пройти проверку fsck для vfat и проверку заголовка, выполняемую ядром при монтировании vfat. Файловая система vfat ядра не требует фиксированного magic value в самом начале раздела, поэтому теоретически это могло бы сработать. Однако несколько полей заголовка FAT действительно важны для ядра, а blkid одновременно выполняет sanity checks суперблоков, поэтому демонстрация использует другой путь.

После того как blkid прочитает части файловой системы и определит тип, label и UUID, fsck_msdos и реализация ядра повторно читают те же данные, причём запросы доходят до накопителя. Ядро Linux кеширует страницы блочного устройства при прямой работе пользовательского пространства, но __blkdev_put() удаляет все связанные с устройством кешированные данные при закрытии последнего открытого файла.

Физический атакующий может воспользоваться этим, подключив поддельное устройство хранения, которое возвращает разные данные при нескольких чтениях одного участка. Например, blkid можно показать заголовок romfs с длинной label, а fsck_msdos и ядру — совершенно обычную файловую систему vfat.

На практике это сравнительно легко реализовать благодаря встроенной в Linux поддержке USB device-side. Доклад Andrzej Pietrasiewicz 2018-09-10-make-your-own-usb-gadget.pdf (файл в files/2018-09-10-make-your-own-usb-gadget.pdf) служит полезным введением. Ядро поставляется с реализациями device-side USB mass storage, HID, Ethernet-адаптеров и других устройств. Через достаточно простой конфигурационный интерфейс на основе псевдофайловой системы можно настроить composite gadget, предоставляющий подключённому устройству одну или несколько таких функций, возможно в нескольких экземплярах. Нужна система с Linux и поддержкой device-side USB; для тестирования использовался Raspberry Pi Zero W.

Функция gadget f_mass_storage рассчитана на обычный файл как backing storage. Чтобы интерактивно отвечать на запросы Android-телефона, вместо него используется файловая система FUSE с параметром direct_io / флагом FOPEN_DIRECT_IO, не позволяющим нашему ядру добавить нежелательное кеширование.

На этом этапе уже можно создать атаку, похищающую, например, фотографии из внешнего хранилища. К счастью для атакующего, сразу после монтирования USB-накопителя запускается com.android.externalstorage/.MountReceiver — процесс, чей домен SELinux разрешает доступ к USB-устройствам. Поэтому после монтирования вредоносного раздела FAT поверх /data с label ' UUID="../../data' zygote создаёт дочерний процесс с подходящим контекстом SELinux и членством в группе для доступа к USB. Затем он загружает байт-код из /data/dalvik-cache/, позволяя захватить com.android.externalstorage, который имеет необходимые привилегии для вывода содержимого внешнего хранилища.

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

Основное ограничение состоит в том, что, хотя поверх /data можно смонтировать свою файловую систему, большая часть высокопривилегированного кода устройства не имеет права обращаться к ней. Но доступ есть у одной высокопривилегированной службы: vold.

vold поддерживает два типа USB-накопителей: PublicVolume и PrivateVolume. До сих пор речь шла о PublicVolume; дальше важен PrivateVolume.

PrivateVolume — USB-накопитель, который должен быть размечен GUID Partition Table. Он содержит раздел с type UUID kGptAndroidExpand (193D1EA4-B3CA-11E4-B075-10604B889DCF), внутри которого находится зашифрованная dm-crypt файловая система ext4 или f2fs. Соответствующий ключ хранится в /data/misc/vold/expand_{partGuid}.key, где {partGuid} — GUID раздела из GPT в виде нормализованной строки шестнадцатеричных цифр нижнего регистра.

В норме атакующий не может так смонтировать ext4, поскольку на телефоне обычно нет нужных ключей; даже при наличии ключа пришлось бы знать правильные GUID раздела и сам ключ. Но мы можем смонтировать vfat поверх /data/misc и поместить туда собственный ключ для собственного GUID. Затем, пока первое вредоносное USB mass storage всё ещё подключено, подключается второе, которое монтируется как PrivateVolume с ключами, читаемыми vold с первого устройства. Технически порядок в предыдущем предложении не совсем точен: эксплойт одновременно предоставляет оба накопителя как единое composite device, но задерживает первое чтение со второго, чтобы добиться нужной последовательности.

Поскольку PrivateVolume использует ext4, мы можем управлять владельцами DAC и разрешениями файловой системы, а благодаря способу интеграции PrivateVolume в систему — даже labels SELinux.

Итак, теперь поверх /data можно смонтировать управляемую файловую систему с произвольными разрешениями и контекстами SELinux. Управляя ими, мы разрешаем любому процессу обращаться к файлам нашей системы, включая их отображение с PROT_EXEC.

Процесс zygote достаточно привилегирован, хотя и не числится частью TCB. По архитектуре он работает с UID 0, может произвольно менять UID и выполнять динамические переходы SELinux в контексты system_server и обычных приложений. Иными словами, zygote имеет доступ почти ко всем пользовательским данным устройства.

При запуске 64-битного zygote во время загрузки системы он загружает код из /data/dalvik-cache/arm64/system@framework@boot*.{art,oat,vdex}. Обычно oat-файл, содержащий ELF-библиотеку для загрузки через dlopen(), и vdex являются символическими ссылками на файлы неизменяемого раздела /system; только art действительно хранится в /data. Но вместо этого system@framework@boot.art и system@framework@boot.vdex можно сделать ссылками на /system, чтобы пройти некоторые проверки согласованности, не зная точной сборки Android, а собственную вредоносную ELF-библиотеку поместить в system@framework@boot.oat с контекстом SELinux легитимного oat-файла. Функция с __attribute__((constructor)) в библиотеке даст выполнение кода в zygote сразу после вызова dlopen() при запуске.

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

Эта часть немного неприятна.

Когда критический системный компонент, в частности zygote или system_server, аварийно завершается, что на eng-сборке можно имитировать командой kill, Android пытается автоматически восстановиться, перезапуская большинство процессов пользовательского пространства, включая zygote. Экран сначала ненадолго показывает анимацию загрузки, затем экран блокировки с запросом «Unlock for all features and data», обычно появляющимся только после загрузки. Однако ключевой материал для доступа к пользовательским данным всё ещё находится в памяти, что при включённом ADB можно подтвердить командой ls /sdcard.

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

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

Эксперименты показали, что код Android для учёта трафика имеет защитную проверку: если он не может записать данные на диск, а с последней успешной записи наблюдалось не менее 2 МиБ (mPersistThresholdBytes) сетевого трафика, выбрасывается фатальное исключение. Значит, можно создать сетевое соединение с устройством, отправить не менее 2 МиБ ping flood, а затем вызвать запись статистики, дождавшись периодической операции или изменив состояние сетевого интерфейса; устройство перезагрузится.

Создать сетевое соединение можно двумя способами:

• Подключиться к сети Wi-Fi. До Android 9 даже на заблокированном устройстве обычно можно подключиться к новой сети: потянуть сверху экрана, нажать раскрывающий элемент под значком Wi-Fi, затем выбрать имя открытой сети. Для защищённых WPA сетей это не работает, но атакующий может создать собственную открытую сеть. Многие устройства также автоматически подключаются к сетям с определёнными именами.

• Подключиться к Ethernet. Android поддерживает USB Ethernet-адаптеры и автоматически входит в проводные сети.

Для тестирования эксплойта использовалось вручную созданное подключение к Wi-Fi; более надёжный и удобный эксплойт, вероятно, применял бы Ethernet.

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

Хотя zygote не считается частью TCB, он имеет capability CAP_SYS_ADMIN в исходном пространстве имён пользователя, и политика SELinux разрешает её использование. Zygote применяет capability для системного вызова mount() и установки seccomp-фильтра без флага NO_NEW_PRIVS. Злоупотребить CAP_SYS_ADMIN можно несколькими способами; на Pixel 2 выглядят жизнеспособными следующие:

• Установить seccomp-фильтр без NO_NEW_PRIVS, затем выполнить execve() с переходом привилегий: SELinux exec transition, setuid/setgid или запуск с разрешёнными file capabilities. Фильтр может заставить определённые системные вызовы завершаться ошибкой с номером 0. Например, для open() процесс поверит, что вызов успешен и выделил файловый дескриптор 0. Здесь атака работает, но получается довольно неопрятной.

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

• Использовать pivot_root() для замены корневого каталога текущего или нового пространства имён монтирования, обходя проверки SELinux, которые выполнялись бы для mount(). Новое пространство имён полезно, когда нужно затронуть только дочерний процесс до повышения его привилегий. Метод не работает, если корневая файловая система — rootfs. Именно эта техника используется здесь.

В новых версиях Android изменился механизм создания дампов аварийно завершившихся процессов. Вместо запроса привилегированному демону процессы запускают одну из вспомогательных программ /system/bin/crash_dump64 и /system/bin/crash_dump32 с label SELinux u:object_r:crash_dump_exec:s0. Сейчас запуск файла с такой label из любого домена SELinux автоматически вызывает переход в домен crash_dump. Это также автоматически устанавливает флаг AT_SECURE во вспомогательном векторе, приказывая linker нового процесса осторожно обращаться с переменными окружения вроде LD_PRELOAD.

domain.te Android SELinux:

На момент сообщения об ошибке домен crash_dump имел следующую политику SELinux:

crash_dump.te Android SELinux:

Политика разрешала crash_dump подключаться через ptrace() к процессам почти любого домена, предоставляя возможность захватить процесс при прохождении проверок DAC, и читать свойства любого процесса в procfs. В списке исключений ptrace указано несколько процессов TCB, но vold в нём отсутствует. Поэтому, если выполнить crash_dump64 и каким-то образом внедрить в него код, затем можно захватить vold.

Обратите внимание: фактическая возможность ptrace() процесса всё ещё ограничена обычными проверками DAC Linux, а crash_dump не может использовать CAP_SYS_PTRACE или CAP_SETUID. Если обычному приложению удастся внедрить код в crash_dump64, несоответствие UID всё равно не позволит применить это для атаки на системные компоненты.

Внимательный читатель может спросить, нельзя ли просто поместить собственный бинарный файл с контекстом u:object_r:crash_dump_exec:s0 в поддельную файловую систему /data и выполнить его для перехода в домен crash_dump. Это не работает, поскольку vold совершенно разумно жёстко задаёт флаг MS_NOSUID при монтировании USB storage. Он ограничивает не только классические setuid/setgid-файлы, но и файлы с file capabilities, а также запуски, которые обычно вызывают автоматические переходы доменов SELinux, если только политика явно не исключает такое поведение разрешением PROCESS2__NOSUID_TRANSITION.

Чтобы внедрить код в crash_dump64, создаётся новое пространство имён монтирования через unshare() с нашей CAP_SYS_ADMIN, затем pivot_root() направляет корневой каталог процесса в полностью контролируемый каталог, после чего запускается crash_dump64. Ядро разбирает ELF-заголовки crash_dump64, читает путь к linker /system/bin/linker64, загружает linker по этому пути относительно корня процесса, поэтому здесь можно предоставить собственный, и выполняет его.

Теперь можно выполнять произвольный код в контексте crash_dump и через него повысить привилегии до vold, скомпрометировав TCB. С точки зрения политики безопасности Android это уже привилегии, эквивалентные ядру. Но чтобы показать дальнейший путь до выполнения в ядре, статья идёт немного дальше.

kernel.te Android SELinux содержит:

Если код в контексте ядра выполняет контролируемый атакующим файл init_exec с файловой системы без MS_NOSUID, тот запускается в контексте init.

Механизм Linux usermode helpers позволяет заставить ядро выполнить такой файл. В частности, поиск несуществующего ключа через request_key() вызывает жёстко заданный путь /sbin/request-key, если ядро не было собрано с другим CONFIG_STATIC_USERMODEHELPER_PATH. Из vold атакующий монтирует управляемую ext4 поверх /sbin без MS_NOSUID, вызывает request_key(), и ядро запускает контролируемую вспомогательную программу в контексте init.

На этом эксплойт останавливается, но поверх него можно построить выполнение в ядре. Из init исполняемый файл с подходящей label может перейти в modprobe или vendor_modprobe:

Эти домены могут загружать модули ядра из файлов с подходящими labels:

Android не требовал подписей модулей ядра:

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

Примечательно, что атака пересекает две слабо обеспеченные границы безопасности: от blkid_untrusted к vold, когда vold доверяет непроверенному UUID в пути, и от zygote к TCB через CAP_SYS_ADMIN процесса zygote. Поставщики ПО справедливо подчёркивают, что исследователи должны понимать, что является границей безопасности, а что нет. Но поставщики также обязаны решать, где такие границы должны существовать, и строго обеспечивать их. Необеспеченные границы могут помогать разработке, пока строится более строгая изоляция, но способны скрывать критичность компонента для безопасности системы в целом.

Исправления вошли в стабильные upstream-выпуски 4.18.9, 4.14.71, 4.9.128, 4.4.157 и 3.16.58.

Когда в пользовательском пространстве возникает page fault, например из-за необходимости подгрузить страницу по требованию, ядро Linux должно найти VMA, virtual memory area (struct vm_area_struct), содержащую адрес сбоя, чтобы определить способ обработки. Медленный путь поиска VMA в find_vma() обходит красно-чёрное дерево областей. Чтобы избежать этих затрат, Linux также имеет быстрый путь, пропускающий обход, если VMA недавно использовалась.

Реализация fastpath менялась; начиная с версии 3.15 Linux использует отдельные для каждого потока кеши VMA с четырьмя слотами, реализованные в mm/vmacache.c и include/linux/vmacache.h. После успешного поиска через slowpath функция vmacache_update() сохраняет указатель VMA в элементе массива current->vmacache.vmas, позволяя следующему поиску использовать fastpath.

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

Для решения struct mm_struct и потоковая struct vmacache помечаются sequence numbers. Когда fastpath в vmacache_valid() обнаруживает несовпадение current->vmacache.seqnum и current->mm->vmacache_seqnum, он очищает кеш текущего потока и обновляет его sequence number.

Sequence numbers mm_struct и кеша VMA имели ширину только 32 бита и могли переполняться. Чтобы кеш не мог ошибочно выглядеть действительным после фактического увеличения current->mm->vmacache_seqnum 2^32 раз, vmacache_invalidate(), увеличивающая current->mm->vmacache_seqnum, обрабатывала особый случай. При переходе current->mm->vmacache_seqnum в ноль она вызывала vmacache_flush_all() для очистки всех кешей VMA, связанных с current->mm. Выполнение vmacache_flush_all() было очень дорогим: функция обходила каждый поток всей машины, проверяла связанную с ним struct mm_struct и при необходимости очищала кеш.

В версии 3.16 добавили оптимизацию: если struct mm_struct связана только с одним потоком, vmacache_flush_all() ничего не делала. Авторы исходили из того, что каждой инвалидации кеша VMA предшествует поиск VMA, поэтому в однопоточном процессе sequence number кеша всегда близок к номеру mm_struct:

Однако оптимизация неверна, поскольку не учитывает ситуацию, когда прежде однопоточный процесс создаёт новый поток сразу после перехода sequence number mm_struct через ноль. В таком случае номер кеша VMA первого потока остаётся равным 0xffffffff, а второй поток может снова увеличить номер mm_struct до 0xffffffff. Тогда кеш первого потока, способный содержать висячие указатели, вновь будет считаться действительным, разрешая использование освобождённых указателей VMA.

Ошибка была исправлена расширением sequence numbers до 64 бит, что делает переполнение непрактичным, и удалением логики обработки переполнения.

По сути, активировать ошибку может любой процесс, способный работать достаточно долго для переполнения счётчика — около часа, если доступен MAP_FIXED, — и использовать mmap() / munmap() для управления mappings памяти и clone() для создания потока. Эти системные вызовы не требуют привилегий и часто разрешены даже в seccomp-песочницах: рендерере Chrome (mmap, munmap, clone), песочнице основного хост-компонента gVisor и seccomp-политике Docker.

Для простоты мой эксплойт использует и другие интерфейсы ядра, поэтому не работает непосредственно внутри таких песочниц. В частности, он читает журналы dmesg через /dev/kmsg и с помощью массива eBPF заполняет страничный аллокатор ядра управляемыми, изменяемыми выделениями по одной странице. Однако атакующий, готовый вложить больше времени, вероятно, смог бы обойтись без этих интерфейсов.

Интересно, что Docker в конфигурации по умолчанию, по-видимому, не запрещает контейнерам доступ к журналам dmesg хоста, если ядро разрешает обычным пользователям читать dmesg. Хотя /dev/kmsg в контейнере отсутствует, seccomp-политика почему-то помещает системный вызов syslog() в белый список.

Первое обращение use-after-free происходит в vmacache_find(). В первоначальной версии функции, существовавшей до появления ошибки, кеш VMA обрабатывался так:

Обнаружив кешированную VMA, границы которой содержат переданный адрес addr, код проверял совпадение указателя ->vm_mm с ожидаемой mm_struct. Оно должно существовать всегда, кроме случаев нарушения безопасности памяти. При несовпадении поток завершался через assertion BUG_ON(). Проверка BUG_ON() предназначена для ситуаций, когда поток ядра обнаруживает серьёзную проблему, которую нельзя корректно обработать выходом из текущего контекста. В стандартной upstream-конфигурации ядра BUG_ON() обычно выводит backtrace и дампы регистров в буфер dmesg, после чего принудительно завершает текущий поток. Иногда это мешает остальной системе продолжить работу: например, если аварийный код удерживал важную блокировку, другие пытающиеся получить её потоки навсегда заблокируются. Но часто остальная система сохраняет достаточно рабочее состояние. Только если ядро определяет, что сбой произошёл в критическом контексте вроде обработчика прерывания, вся система останавливается с kernel panic.

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

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

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

Ядро предоставляет два sysctl для настройки поведения в зависимости от желаемого компромисса:

• kernel.panic_on_oops автоматически вызывает kernel panic при срабатывании BUG_ON() или сбое ядра; начальное значение задаётся параметром сборки CONFIG_PANIC_ON_OOPS. В upstream-ядре он по умолчанию выключен, и включать его по умолчанию в дистрибутивах, вероятно, было бы плохой идеей, однако Android включает его.

• kernel.dmesg_restrict определяет, могут ли пользователи без root читать dmesg, где среди прочего находятся дампы регистров и трассировки стека после сбоев ядра; начальное значение задаётся CONFIG_SECURITY_DMESG_RESTRICT. В upstream он по умолчанию выключен, но некоторые дистрибутивы, например Debian, включают его. Android блокирует доступ к dmesg через SELinux.

Ubuntu, например, не включает ни один из параметров.

Приведённый выше фрагмент изменили в том же месяце, когда он был добавлен:

Именно эту изменённую версию сейчас поставляют дистрибутивы вроде Ubuntu.

Первое изменение переносит проверку висячего указателя перед сравнением адресов. Второе интереснее: BUG_ON() заменена на WARN_ON_ONCE().

WARN_ON_ONCE() выводит в dmesg отладочные сведения, похожие на вывод BUG_ON(). В отличие от BUG_ON(), WARN_ON_ONCE() выводит их только при первом срабатывании и продолжает выполнение. Теперь, обнаружив висячий указатель в fastpath кеша VMA, то есть эвристически выявив use-after-free, ядро просто покидает fastpath и возвращается к обходу красно-чёрного дерева. Процесс продолжает работать.

Это соответствует политике ядра по умолчанию максимально сохранять систему работоспособной. Если по какой-то причине здесь случайно происходит use-after-free, ядро, вероятно, может эвристически смягчить последствия и продолжить работу процесса.

Политика вывода лишь предупреждения даже при обнаружении повреждения памяти ядра проблематична для систем, которые должны вызывать kernel panic при событиях, относящихся к безопасности. Простое превращение WARN() в kernel panic неприемлемо, поскольку WARN() используется и для множества событий, не важных для безопасности ядра. Поэтому некоторые применения WARN_ON() в чувствительных местах заменили на CHECK_DATA_CORRUPTION(), позволяющий на этапе конфигурации выбирать между BUG() и WARN(). Но CHECK_DATA_CORRUPTION() используется только в коде работы со связными списками и addr_limit_user_check(); проверка кеша VMA по-прежнему применяет обычный WARN_ON_ONCE().

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

После этого изменения sanity check полностью пропускается, если ядро не собрано с отладочным параметром CONFIG_DEBUG_VM_VMACACHE.

Эксплойту необходимо увеличить sequence number приблизительно 2^33 раз. Поэтому эффективность примитива увеличения критична для общего времени работы.

За один системный вызов можно добиться двух увеличений. Сначала создаётся анонимная VMA, охватывающая три страницы. Затем mmap() с MAP_FIXED многократно заменяет среднюю страницу эквивалентной VMA. mmap() сначала разделяет область на три VMA, затем заменяет среднюю и снова объединяет три области, вызывая инвалидацию кеша для двух VMA, удаляемых при объединении.

Перечислим все потенциальные способы атаковать use-after-free, не возвращая backing page slab-объекта страничному buddy allocator; согласно /proc/slabinfo, ядро Ubuntu использует одну страницу на slab vm_area_struct:

• Повторно использовать vm_area_struct в том же процессе. Тогда процесс сможет пользоваться этой VMA, но ничего интересного не произойдёт, поскольку кешам процесса и так разрешено содержать указатели на неё.

• Освободить vm_area_struct в freelist slab allocator и попытаться обратиться к ней. Однако по крайней мере используемый Ubuntu SLUB заменяет первые восемь байтов vm_area_struct, содержащие vm_start, начальный пользовательский адрес, адресом ядра. Поэтому функция поиска кеша VMA не сможет вернуть объект: условие vma->vm_start <= addr && vma->vm_end > addr невыполнимо.

• Освободить vm_area_struct в freelist slab allocator, затем выделить её в другом процессе. За исключением очень узкой гонки, которую трудно вызывать многократно, это приведёт к WARN_ON_ONCE(), и функция поиска не вернёт VMA.

• Освободить vm_area_struct в freelist slab allocator, затем выполнить выделение из slab, объединённого со slab vm_area_struct. Для этого нужен aliasing slab; в виртуальной машине Ubuntu 18.04 такого, по-видимому, нет.

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

Страницы pipe:

• Преимущество: не очищаются при выделении.

• Преимущество: при наличии splice() допускают запись по произвольному смещению внутри страницы.

• Преимущество: выровнены по странице.

• Недостаток: нельзя выполнить несколько записей, не освободив и не выделив страницу повторно.

Карты BPF:

• Преимущество: содержимое можно многократно читать и записывать из пользовательского пространства.

• Преимущество: выровнены по странице.

• Недостаток: очищаются при выделении.

Эксплойт использует карты BPF.

Ему нужны следующие сведения:

• Адрес mm_struct.

• Адрес VMA с use-after-free.

• Адрес загрузки кода ядра.

По крайней мере в ядре Ubuntu 18.04 первые два адреса напрямую видны в дампе регистров, вызванном WARN_ON_ONCE(), и легко извлекаются из dmesg: адрес mm_struct находится в RDI, а VMA — в RAX. Указатель инструкций напрямую не виден, поскольку RIP и стек символизированы, а в регистрах общего назначения указателя инструкций нет.

Backtrace ядра может содержать несколько наборов регистров. Когда логика трассировки встречает кадр прерывания, она создаёт дополнительный дамп. Мы можем вызвать WARN_ON_ONCE() через page fault по пользовательскому адресу, а такие faults могут происходить при любом обращении к пользовательской памяти в контексте системного вызова через copy_from_user() / copy_to_user() и другие функции. Это позволяет выбрать место вызова, где нужные сведения находятся в регистре, из множества вариантов. Оказалось, что запись в eventfd вызывает usercopy, пока R8 ещё содержит указатель на структуру eventfd_fops.

Во время работы эксплойт заменяет VMA нулевой памятью, а затем запускает поиск VMA через повреждённый кеш, намеренно вызывая WARN_ON_ONCE(). Создаётся следующее предупреждение; используемые эксплойтом утечки выделены в исходном материале:

Теперь эксплойт может создать поддельную VMA с правильным указателем mm_struct, утёкшим из RDI. Другие поля заполняются ссылками на поддельные структуры данных, то есть указателями обратно в fake VMA, построенными по утёкшему из RAX адресу VMA, и указателями на код ядра с использованием R8 из кадра исключения page fault для обхода KASLR.

Вероятно, ошибку можно эксплуатировать изящнее, например наложив поддельную записываемую VMA на существующие страницы только для чтения. Однако этот эксплойт использует классическое jump-oriented programming.

Чтобы второй раз активировать use-after-free, выполняется запись по адресу без элементов таблицы страниц. Обработчик page fault ядра проходит цепочку page_fault -> do_page_fault -> __do_page_fault -> handle_mm_fault -> __handle_mm_fault -> handle_pte_fault -> do_fault -> do_shared_fault -> __do_fault, где выполняется косвенный вызов:

vma — контролируемая нами структура VMA, поэтому здесь мы получаем управление указателем инструкций. R13 содержит указатель на vma. Дальнейшая JOP-цепочка довольно груба, например после выполнения задачи она приводит к сбою, но работает.

Сначала перемещаем указатель VMA в RDI:

Затем получаем полный контроль над RDI:

Теперь можно вызвать run_cmd(), которая запускает usermode helper с правами root, принимая единственным аргументом разделённый пробелами путь и список параметров. Это позволяет выполнить предоставленный нами бинарный файл с root. Спасибо Mark за подсказку: контролируя RDI и RIP, не нужно делать ничего безумного вроде переключения битов SM*P в CR4, достаточно запустить usermode helper.

После запуска helper ядро падает с page fault, поскольку JOP-цепочка не завершается корректно. Но сбой убивает только процесс, в чьём контексте произошёл fault, поэтому это не имеет особого значения.

Об ошибке сообщили 12 сентября 2018 года. Через два дня, 14 сентября, исправление уже находилось в upstream-дереве ядра. По сравнению со сроками других поставщиков ПО это исключительно быстро. С этого момента downstream-поставщики теоретически могли перенести и применить патч. Ошибка фактически становится публичной уже тогда, даже если commit message скрывает её влияние на безопасность, что неоднократно демонстрировал grsecurity.

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

1. Патч попадает в upstream-ядро.

2. Патч переносится в поддерживаемое upstream стабильное ядро.

3. Дистрибутив вливает изменения из upstream stable в свои ядра.

4. Пользователи устанавливают новое ядро дистрибутива.

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

В данном случае backport в поддерживаемые upstream стабильные ядра 4.18, 4.14, 4.9 и 4.4 был опубликован 19 сентября 2018 года — через пять дней после публикации патча, когда дистрибутивы смогли его забрать.

Обновления стабильных upstream-ядер выходят очень часто. Например, последние на тот момент выпуски стабильного ядра 4.14, самого нового upstream longterm release:

• 4.14.72 от 26 сентября 2018 года

• 4.14.71 от 19 сентября 2018 года

• 4.14.70 от 15 сентября 2018 года

• 4.14.69 от 9 сентября 2018 года

• 4.14.68 от 5 сентября 2018 года

• 4.14.67 от 24 августа 2018 года

• 4.14.66 от 22 августа 2018 года

Ядра 4.9 и 4.4 с длительной поддержкой обновляются столь же часто. Только longterm-ядро 3.16 не получало обновлений между последним выпуском от 25 сентября 2018 года (3.16.58) и предыдущим от 16 июня (3.16.57).

Однако дистрибутивы Linux зачастую публикуют обновления ядра значительно реже. Например, Debian stable поставляет ядро на основе 4.9, но на 26 сентября 2018 года оно последний раз обновлялось 21 августа. Аналогично Ubuntu 16.04 поставляла ядро, 2018-09-26-ubuntu-linux-changelog.txt (файл в files/2018-09-26-ubuntu-linux-changelog.txt). Android выпускает обновления безопасности только раз в месяц. Поэтому даже при наличии критического исправления в upstream stable до его фактического появления у пользователей могут пройти недели, особенно если влияние на безопасность не объявлено публично.

В данном случае проблема безопасности была объявлена в списке рассылки oss-security 18 сентября 2018 года, а CVE выделили 19 сентября, сделав необходимость выпуска новых дистрибутивных ядер понятнее. И всё же на 26 сентября Debian и Ubuntu в версиях 16.04 и 18.04 отмечали ошибку как неисправленную:

• Трекер безопасности Debian: CVE-2018-17182

• Трекер CVE Ubuntu: CVE-2018-17182

Fedora отправила обновление пользователям 22 сентября: комментарий 8 в Red Hat Bugzilla.

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

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

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

Итак, перенесёмся обратно в 2014 год...

Pangu 7

23 июня 2014 года @PanguTeam выпустила джейлбрейк Pangu 7 для iOS 7.1–7.1.x. Команда эксплуатировала множество ошибок. Нас интересует CVE-2014-4461, которую Apple описала так:

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

Описание: при обработке некоторых полей метаданных объектов IODataQueue существовала ошибка проверки. Проблема устранена улучшенной проверкой метаданных.

(На самом деле эта ошибка ядра не была исправлена в iOS 8, и Pangu повторно использовала её в Pangu 8...)

Очередное любопытство...

В примечаниях к выпуску эпохи iOS 8 видно, что мы с Pangu нашли несколько ошибок в похожих областях:

IOKit

Доступно для: iPhone 4s и новее, iPod touch (5-го поколения) и новее, iPad 2 и новее

Воздействие: вредоносное приложение может получить возможность выполнять произвольный код с системными привилегиями

Описание: при обработке некоторых полей метаданных объектов IODataQueue существовала ошибка проверки. Проблема устранена улучшенной проверкой метаданных.

CVE-2014-4418: Иэн Бир из Google Project Zero

IOKit

Доступно для: iPhone 4s и новее, iPod touch (5-го поколения) и новее, iPad 2 и новее

Воздействие: вредоносное приложение может получить возможность выполнять произвольный код с системными привилегиями

Описание: при обработке некоторых полей метаданных объектов IODataQueue существовала ошибка проверки. Проблема устранена улучшенной проверкой метаданных.

CVE-2014-4388: @PanguTeam

IOKit

Доступно для: iPhone 4s и новее, iPod touch (5-го поколения) и новее, iPad 2 и новее

Воздействие: вредоносное приложение может получить возможность выполнять произвольный код с системными привилегиями

Описание: при обработке функций IOKit возникало целочисленное переполнение. Проблема устранена улучшенной проверкой аргументов API IOKit.

CVE-2014-4389: Иэн Бир из Google Project Zero

IODataQueue

Я изучал класс IOKit IODataQueue, о котором заголовочный файл IODataQueue.h говорит: «предназначен для того, чтобы код ядра мог ставить данные в очередь для пользовательского процесса». Для этого он создаёт в общей памяти неблокирующую структуру данных очереди.

IODataQueue был довольно прост: в нём было всего два поля — dataQueue и notifyMsg:

Ниже приведена полная реализация IODataQueue в том виде, в каком она существовала примерно во времена iOS 7.1.2:

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

При первом вызове метод ::setNotificationPort выделяет через IOMalloc структуру заголовка Mach-сообщения и сохраняет этот буфер в notifyMsg.

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

Наконец, ::getMemoryDescriptor создаёт объект IOMemoryDescriptor, оборачивающий память dataQueue для возврата в пространство пользователя.

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

Это приводит к очевидным повреждениям памяти в ::enqueue: пространство пользователя может изменить поля queueSize, head и tail, а ядро никак не проверяет, находятся ли они в пределах буфера очереди. Два других места, использующих queueSize, также доверяют значению из общей памяти, из-за чего в IOFreeAligned передаётся неверный размер, а в пространство пользователя возвращается чрезмерно большой дескриптор памяти.

Снова к Pangu

Ошибка Pangu, позволявшая выполнять код в ядре, находилась не в IODataQueue, а в подклассе IOSharedDataQueue. В IOSharedDataQueue.h сказано, что «класс IOSharedDataQueue предназначен также для того, чтобы пользовательский процесс мог ставить данные в очередь для кода ядра».

IOSharedDataQueue добавляет одно неиспользуемое поле:

IOSharedDataQueue не переопределяет метод ::enqueue, но добавляет ::dequeue, позволяющий ядру извлекать объекты, поставленные в очередь пространством пользователя.

У ::dequeue были те же проблемы, что и у ::enqueue: размер очереди находился в общей памяти, поэтому ядро могло читать за границами буфера. Но, как ни странно, это было не единственным изменением в IOSharedDataQueue. Pangu заметила, что IOSharedDataQueue также переопределяет метод ::initWithCapacity:

IOSharedDataQueue увеличивает размер буфера общей памяти, добавляя место для структуры IODataQueueAppendix:

Она содержит поле версии и, что странно, заголовок Mach-сообщения. Затем в строке:

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

Напомним, что при первой установке порта уведомлений IODataQueue выделял структуру заголовка Mach-сообщения через IOMalloc. Почему же IOSharedDataQueue поступает иначе? Единственное правдоподобное объяснение, которое я могу предложить: разработчик хотел избежать небольшого выделения памяти в куче ядра и решил разместить сообщение в уже существующем общем буфере.

Но можно ли вообще помещать заголовок Mach-сообщения в общую память таким образом?

Что находится в сообщении?

Вот определение mach_msg_header_t в iOS 7.1.2:

(После появления ваучеров поле msgh_reserved превратилось в msgh_voucher_port.)

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

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

Ядро:

В пространстве пользователя mach_port_t — беззнаковое 32-битное целое число, локальное для задачи имя порта. В ядре же mach_port_t — настоящий указатель на нижележащую структуру ipc_port.

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

Перенесёмся вперёд

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

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

Очереди пространства пользователя и deja-xnu

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

Кода создания этих очередей нет в пакете IOKitUser с открытым исходным кодом: эту функциональность можно увидеть только при обратной разработке бинарного файла IOKit framework.

В исходном коде IOKitUser этот код нигде не используется, но обратная разработка показала, что очереди только для пространства пользователя применялись службой MIG com.apple.iohideventsystem, реализованной в IOKit.framework и размещённой в backboardd на iOS и hidd на macOS.

Читая пользовательский метод __IODataQueueEnqueue, который ставит объекты и в пользовательские, и в ядерные очереди, я испытал сильное чувство deja-xnu: он доверял значению queueSize в заголовке очереди в общей памяти — точно так же, как старый код ядра.

Продолжив изучать пользовательский код обработки IODataQueue, я заметил, что в отличие от ядерного объекта IODataQueue пользовательский вариант имел не только заголовок, но и дополнительную структуру. Как и в IOSharedDataQueue, в ней хранился заголовок Mach-сообщения. Функция установки порта уведомлений выглядела так:

Можно заглянуть в содержимое буфера через lldb и увидеть, что в конце очереди, всё ещё в общей памяти, находится заголовок Mach-сообщения, а в поле имени записано имя удалённой стороны предоставленного нами порта уведомлений!

Эксплуатация произвольной отправки Mach-сообщения

В XNU у каждой задачи (процесса) есть task port, а у каждого потока внутри задачи — thread port. Изначально право отправки в task port задачи давало полный контроль над её памятью и потоками, а право отправки в thread port означало полный контроль над потоком, который легко превратить в контроль над памятью. Таким образом, эти порты представляют собой чрезвычайно мощные возможности.

Из-за эксплойтов, опубликованных мной и другими исследователями и использовавших проблемы Mach-портов для кражи прав на порты, Apple очень медленно усиливала защиту этих интерфейсов. Но даже в iOS 11.4.1, имея право отправки в thread port другого процесса, всё ещё можно добиться выполнения кода в этом процессе.

Интересно, что запуск процессов в iOS достаточно детерминирован: в backboardd имя 0x407 обозначает thread port как на iOS 7.1.2 на iPhone 4, так и на iOS 11.4.1 на iPhone SE.

Кража портов

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

Эксплойт для этой проблемы нацелен на iOS 11.4.1 и содержит изменённую версию кода remote_call из triple_fetch, способную работать с украденным thread port вместо task port.

Снова в 2014 год

Я упоминал, что Apple постепенно добавляла меры защиты от использования украденных task port. Первая известная мне мера запретила пространству пользователя использовать kernel task port, часто называемый task-for-pid-0 или TFP0, то есть task port, представляющий задачу ядра.

До этого усиления защиты право отправки в kernel task port давало полный доступ на чтение и запись памяти ядра.

Мы уже увидели, что распределение имён портов чрезвычайно стабильно: одно и то же имя thread port сохранялось четыре года. А насколько похожа ситуация с указателями ipc_port, используемыми ядром в Mach-сообщениях?

Выделение самых ранних портов ядра также детерминировано. Я использовал это в mach_portal, чтобы украсть kernel task port: сначала определил адрес host port, а затем предположил, что kernel task port должен находиться рядом, поскольку оба выделяются на очень ранней стадии загрузки.

В 2014 году всё было ещё проще: kernel task port находился по фиксированному смещению относительно host port. Достаточно узнать адрес host port, после чего можно вычислить адрес kernel task port!

Определение адресов портов

IOHIDEventService — это userclient, предоставляющий пространству пользователя IOSharedDataQueue. Открыть его из песочницы приложения нельзя, но эксплойт пользовательской ошибки IODataQueue было достаточно легко перенести на 32-битную iOS 7.1.2, чтобы получить выполнение кода в backboardd, который находится вне песочницы приложения.

Песочница мешает лишь непосредственно открыть соединение с userclient. После этого мы можем передать Mach-порт, представляющий соединение, обратно в приложение в песочнице и продолжить эксплуатацию уже оттуда. С использованием кода, написанного для triple_fetch, открытие userclient из backboardd выглядит так:

Затем достаточно вызвать внешний метод 0, чтобы «открыть» очередь, и IOConnectMapMemory, чтобы отобразить общую память очереди в наш процесс и найти заголовок Mach-сообщения:

Чтобы установить порт уведомлений очереди, нужно вызвать для userclient функцию IOConnectSetNotificationPort:

После этого в сообщении в общей памяти виден адрес ipc_port этого порта в ядре:

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

На самом деле эту ошибку возвращает клиентский код MIG, сообщая, что сериализованное MIG-сообщение не удалось отправить. IOConnectSetNotificationPort — тонкая обёртка над сгенерированным MIG клиентским кодом io_connect_set_notification_port. Рассмотрим определение MIG:

Здесь видно, что аргумент порта определён как mach_port_make_send_t. Это означает, что код MIG передаст аргумент порта в дескрипторе порта с disposition MACH_MSG_TYPE_MAKE_SEND, для чего отправитель должен иметь право приёма, а не право отправки. Чтобы обойти это ограничение, можно вставить право отправки в host port под новым именем в собственном пространстве имён IPC, а затем использовать это имя как право приёма при ручном формировании запроса.

Сделав это и передав имя, полученное от mach_host_self(), мы узнаем адрес host port в ядре:

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

Из исходного кода XNU видно, что host port выделяется раньше kernel task port. Поскольку это было до появления рандомизации freelist распределителя зон, адрес kernel task port, вероятно, находится ниже адреса host port на небольшое фиксированное кратное 0x70.

Если установить в поле msgh_local_port адрес host port минус 0x70, а затем уменьшать его на 0x70 при каждом получении сообщения уведомления, с каждым уведомлением нам будет передаваться другой ранний порт. В конце концов таким способом мы получим право отправки в kernel task port.

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

Мой эксплойт для iOS 7.1.2 доступен здесь; я проверял его только на iPhone 4. Для сборки и запуска потребуется старая версия Xcode — я использую Xcode 7.3.1.

Запустите приложение, нажмите кнопку «Домой», чтобы вызвать сообщение HID-уведомления, и наслаждайтесь доступом на чтение и запись памяти ядра. :)

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

Уроки

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

Не стоит также преуменьшать возможные последствия одной лишь пользовательской версии ошибки. До mach_portal из-за особенности проектирования службы MIG com.apple.iohideventsystem процесс backboardd имел права отправки во множество привилегированных task port. Кража одного из этих портов давала контроль над соответствующей задачей.

Некоторые из этих задач выполнялись от имени root, а значит, могли эксплуатировать уязвимость processor_set_tasks, чтобы получить task port любой задачи на устройстве. Несмотря на то что проблема была известна, её исправили лишь после того, как я использовал её в triple_fetch.

Эта проблема IODataQueue была не единственным вариантом, найденным мной в рамках проекта. Проект deja-xnu для iOS 11.4.1 также содержит PoC-код, вызывающий ошибку генерации кода MIG в клиентах backboardd, а в трекере Project Zero приведены подробности других проблем в связанном коде обработки очередей.

Последнее замечание о бюллетенях безопасности

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

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

Предыдущие проблемы точности

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

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

И вторая ошибка

Следующая уязвимость — use-after-free объекта egl::ImageImplementation, вызванная переполнением счётчика ссылок. С точки зрения эксплуатации это очень удобный объект: из JavaScript можно читать и записывать хранящиеся в нём данные, а операции над изображением приводят к вызовам виртуальных методов.

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

На деле это оказалось самой неприятной частью эксплойта. Команды OpenGL при передаче из WebGL в GPU-процесс проходят несколько уровней проверки, дублирования и копирования: начальную проверку WebGL в renderer, проверку командного буфера GPU, проверку ANGLE и, наконец, проверку SwiftShader. Поэтому трудно найти выделения, и размер, и содержимое которых напрямую управляются из JavaScript.

Однако один хороший примитив существует — uniform-переменные шейдера. Через них параметры передаются программируемым GPU-шейдерам. В коде SwiftShader видно, что при окончательном выделении этих объектов и размер, и содержимое управляются шейдером и вызовами из JavaScript.

Приведённый ниже код реализует этот приём для простейшей подготовки кучи в процессе SwiftShader/GPU, а также оптимизированный способ переполнения счётчика ссылок. Исходный код шейдера создаёт четыре выделения размером 0xf0, каждое из которых содержит управляемые нами значения. Объект egl::ImageImplementation цели рендеринга освобождается посредством переполнения счётчика ссылок, после чего его заменяют выделения uniform-переменных шейдера.

Теперь объект можно изменить так, чтобы он позволял читать и записывать всю память GPU-процесса. В функции read_write показано, как для этого используются методы gl.readPixels и gl.blitFramebuffer.

С этого момента получить произвольное выполнение кода должно быть довольно просто. Хотя выровнять ROP-цепочку при необходимости заменить объект C++ зачастую неприятно, это вполне решаемая задача. Однако оказалось, что SwiftShader предоставляет гораздо более чистый путь.

Для максимальной производительности SwiftShader использует JIT-компиляцию шейдеров. JIT-компилятор задействует другой объект C++, SubzeroReactor::ELFMemoryStreamer, для загрузки и отображения в память сгенерированных исполняемых файлов ELF. Возможно, можно создать поддельный объект, который заставит JIT-загрузчик отобразить нашу полезную нагрузку как исполняемый код.

Это действительно возможно. Создадим поддельную vtable со следующими соответствиями:

После чтения из такого объекта изображения вместо возврата пикселей в JavaScript наша shellcode-нагрузка выполнится в GPU-процессе.

Выводы

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

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

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

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

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

После сигнализации участники находят маршрут трафика друг к другу протоколами STUN, TURN и ICE. По результатам они создают подходящее для сетевых условий соединение UDP, UDP поверх STUN, а иногда TCP.

После установления связи используется Real-time Transport Protocol. Несмотря на стандартизацию, большинство реализаций немного отклоняется от него. RTP можно шифровать протоколом Secure RTP (SRTP), а некоторые решения также применяют DTLS. Внутри шифрования RTP поддерживает одновременный обмен несколькими потоками и форматами. В зависимости от классификации данные передаются другой обработке, например видеокодекам. Во время конференции для небольших объёмов данных, например текстового сообщения поверх звонка, иногда применяется Stream Control Transmission Protocol (SCTP), но реже RTP.

Даже зашифрованный RTP часто не защищает целостность, а если защищает, обычно не отбрасывает повреждённые пакеты. Вместо этого он пытается восстановить их методами вроде Forward Error Correction. Большинство решений обнаруживает шумный или медленный канал и старается поддержать лучшее качество, например отправляя меньше кадров или меняя кодек. Real Time Control Protocol обменивается статистикой качества сети и координирует настройку потоков RTP под условия связи.

WebRTC — проект с открытым исходным кодом для видеоконференций и самая распространённая реализация. Его используют Chrome, Safari, Firefox, Facebook Messenger, Signal и множество мобильных приложений. Благодаря широкому применению, открытому коду и неплохой документации WebRTC выглядел хорошей отправной точкой.

Сигнализация WebRTC

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

Анализ кода парсера SDP не выявил ошибок. Я также собрала его так, чтобы он принимал файл SDP из командной строки, и провела фаззинг, но тоже ничего не нашла. Позднее выяснилось, что браузеры реализуют сигнализацию WebRTC неодинаково: Chrome использует основную реализацию, Safari немного ответвилась, Firefox создала собственную. Большинство мобильных приложений WebRTC также реализует собственную сигнализацию не на SDP. Поэтому ошибка общей сигнализации вряд ли затронет широкий набор целей.

Фаззинг RTP

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

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

Его настройка требовала много времени, поэтому для быстрой оценки я изменила Chrome так, чтобы он отправлял повреждённые RTP-пакеты. Функция srtp_protect библиотеки libsrtp запускала для каждого пакета следующий фаззер:

Фаззер RTP (фаззер q)

При звонке из этой версии WebRTC в неизменённый Chrome сбой происходил примерно каждые 30 секунд.

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

Первая проблема, CVE-2018-6130, представляет собой обращение за границы памяти, связанное с std::map::find при обработке видеокодека VP9. В следующем коде значение tl0_pic_idx берётся из RTP-пакета без проверки (GOF означает group of frames):

Если значения нет в gof_info_, std::map::find возвращает end-итератор, указывающий на элемент после выделенной памяти map. В зависимости от компоновки разыменование либо вызовет сбой, либо вернёт содержимое невыделенной памяти.

Вторая проблема, CVE-2018-6129, — более обычное чтение за границами: индекс поля извлекается из RTP-пакета и без проверки используется для обращения к вектору.

Третья, CVE-2018-6157, — путаница типов при отправке пакета, похожего на VP8, парсеру H264. В итоге он трактуется как H264, хотя не прошёл необходимых проверок. Воздействие также ограничено чтением за границами.

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

Инструмент также значительно ускорил фаззинг: достаточно изменять файл дампа RTP и загружать его в video_replay. Возникали ложные срабатывания из-за ошибок разбора самого формата дампа, но большинство находилось в обработке RTP.

Фаззинг video_replay с включёнными покрытием кода и ASAN выявил ещё четыре ошибки. Для их поиска фаззер около двух недель работал на 50 ядрах.

CVE-2018-6156, вероятно, самая эксплуатируемая. Это большое переполнение FEC. Буфер WebRTC для пакетов FEC имеет размер 1500 байт, но после извлечения из RTP их длина не проверяется. На практике она может достигать примерно 2000 байт.

CVE-2018-6155 — использование после освобождения в кодеке VP8. Ошибка интересна тем, что затрагивает библиотеку VP8 libvpx, а не WebRTC, и потому может влиять на другое ПО. В результате было выпущено общее исправление libvpx.

CVE-2018-16071 — UAF в обработке VP9, отчасти похожее на CVE-2018-6130. Недоверенный индекс снова извлекается из пакета, но теперь используется как верхняя граница операции удаления элементов вектора, что позволяет удалить всё до последующего использования.

CVE-2018-16083 — чтение за границами FEC из-за отсутствующей проверки.

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

Для быстрой проверки эффективности фаззинга я перехватила эту функцию и стала изменять зашифровываемые данные. Обычно для этого достаточно установить переменную среды DYLD_INSERT_LIBRARIES, но avconferenced — демон, автоматически перезапускающийся после завершения, поэтому простого способа задать переменную не было. В конце концов я изменила двоичный файл AVConference инструментом insert_dylib, заставив его загружать библиотеку при запуске, и перезапустила процесс. Загруженная библиотека с помощью DYLD_INTERPOSE заменяла CCCryptorUpdate версией, подвергавшей каждый входной буфер фаззингу инструментом q из части 1 до обработки. У реализации было множество проблем: фаззингу подвергались и шифрование, и расшифровка; затрагивался каждый вызов CCCryptorUpdate из avconferenced, а не только относящийся к SRTP; воспроизвести сбой было невозможно. Тем не менее звонок с изменённого FaceTime на iPhone давал повреждённое видео, а через несколько минут телефон аварийно завершал работу. Это подтвердило, что именно здесь шифруются звонки FaceTime и фаззинг, вероятно, найдёт ошибки.

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

После этого я написала вторую библиотеку, также перехватывавшую CCCryptorUpdate и воспроизводившую зарегистрированные первой библиотекой пакеты, последовательно копируя их в переданные функции буферы. К сожалению, потребовалось немного изменить двоичный файл AVConference. Функция SRTPEncryptData игнорирует длину, возвращаемую CCCryptorUpdate, и предполагает, что длина зашифрованных данных совпадает с длиной открытого текста, что разумно, когда CCCryptorUpdate не перехватывается. Поскольку SRTPEncryptData всегда шифрует на месте в большом буфере фиксированного размера, я изменила функцию так, чтобы она считывала длину зашифрованного буфера из самого его конца, куда значение записывал перехваченный вызов CCCryptorUpdate. Из-за обычно небольшой длины RTP-пакетов эта память вряд ли используется для других целей. Однако даже при воспроизведении тех же зашифрованных данных целевое устройство обрабатывало их неправильно.

Чтобы понять причину, необходимо рассмотреть устройство RTP-пакета.

Пакет содержит несколько полей, влияющих на интерпретацию полезной нагрузки. SSRC — случайный идентификатор потока. Например, потоки звука и видео FaceTime имеют разные SSRC. Они также помогают различать потоки, когда у пользователя их может быть неограниченное число, например при видеозвонке с несколькими участниками. У RTP-пакетов есть и тип полезной нагрузки (PT на схеме), разделяющий разные виды данных. Для определённого вида данных он остаётся одинаковым между звонками. В FaceTime видеопоток использует один тип для видеоданных, а аудиопоток — два, вероятно, один для звука и другой для синхронизации. Поле маркера (M на схеме) FaceTime также применяет, чтобы обозначить фрагментированный пакет, который необходимо собрать.

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

Корректировку полей осложнила функция RTP под названием «расширения». Расширение — необязательный заголовок, добавляемый к RTP-пакету. Для его интерпретации не должна требоваться полезная нагрузка RTP; расширения часто передают сведения о сети или отображении. Среди поддерживаемых примеров есть расширение ориентации, сообщающее конечной точке ориентацию принимающего устройства, и расширение отключения звука, сообщающее, заглушено ли оно.

Из-за расширений даже знание типа полезной нагрузки, маркера и SSRC не позволяет точно воспроизвести отправленный пакет. Более того, FaceTime создаёт расширения после шифрования, поэтому перехватом CCCryptorUpdate нельзя построить полный RTP-пакет: расширения могут добавиться позднее.

Стало понятно, что sendmsg необходимо перехватить наряду с CCCryptorUpdate. Это позволило бы изменить заголовок исходящего RTP после завершения его формирования. Возникло несколько трудностей. Пакеты звука и видео отправляются разными потоками FaceTime и могут поменяться местами между шифрованием и передачей через sendmsg. Поэтому нельзя считать полученный sendmsg RTP-пакет последним зашифрованным. Кроме того, SSRC динамические: воспроизведение пакета с записанным SSRC не сработает, его необходимо заменить новым идентификатором аудио- или видеопотока.

Обратите внимание: в macOS Mojave FaceTime может вызывать sendmsg через двоичный файл AVConference или IDSFoundation в зависимости от конфигурации сети. Поэтому для захвата и воспроизведения незашифрованного трафика RTP в новых системах необходимо перехватывать CCCryptorUpdate в AVConference и sendmsg в IDSFoundation: при вызове sendmsg AVConference обращается к IDSFoundation. В остальном процесс совпадает со старыми системами.

В итоге я реализовала запись незашифрованной полезной нагрузки и её RTP-заголовка, сопоставляя заголовки с правильной открытой нагрузкой по фрагменту зашифрованных данных. Для воспроизведения зашифровываемые в CCCryptorUpdate пакеты заменялись зарегистрированными, а когда зашифрованная нагрузка доходила до sendmsg, её заголовок заменялся записанным заголовком данной нагрузки. К счастью, два потока FaceTime с уникальными SSRC не используют общих типов полезной нагрузки. Поэтому новый SSRC каждого потока можно определить, дождавшись входящего пакета с нужным типом, а затем подставлять правильное значение во все последующие пакеты.

Но и это не обеспечило правильного воспроизведения звонка FaceTime: часто возникали ошибки расшифровки. В конце концов выяснилось, что звук и видео FaceTime шифруются разными ключами. Я изменила сценарий, чтобы он помещал CCCryptor из вызова CCCryptorUpdate в очередь в зависимости от типа содержимого. Затем в sendmsg весь зарегистрированный RTP-пакет вместе с незашифрованной нагрузкой копировался в исходящий пакет, SSRC исправлялся, а нагрузка шифровалась следующим CCCryptor из соответствующей очереди. Если CCCryptor отсутствовал, исходящие пакеты отбрасывались до создания нового. Теперь изменённый двоичный файл AVConference больше не требовался, поскольку все изменения пакетов выполнялись в sendmsg. Однако надёжность реализации всё ещё оставляла желать лучшего.

Более глубокое изучение шифрования FaceTime показало, что пакеты шифруются в режиме CTS, которому требуется счётчик. Для каждого отправляемого пакета он инициализируется уникальным значением. При инициализации RTP-потока стороны обмениваются двумя случайными 16-байтовыми токенами — для звука и видео. Значение счётчика каждого пакета рассчитывается операцией исключающего ИЛИ токена с несколькими значениями пакета, включая SSRC и порядковый номер. Между пакетами меняется только порядковый номер. Поэтому счётчик любого пакета можно вычислить, зная исходные счётчик и порядковый номер, получаемые перехватом CCCryptorCreateWithMode. При построении счётчика FaceTime выполняет исключающее ИЛИ порядкового номера со случайным токеном по индексу 0x12. Если выполнить в этой позиции исключающее ИЛИ сначала с исходным порядковым номером, а затем с номером нужного пакета, получится его счётчик. Ключ также извлекается перехватом CCCryptorCreateWithMode. Теперь вся информация для создания криптора любого пакета была доступна, и очереди стали не нужны. Пакеты начали шифроваться быстрее и точнее.

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

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

CVE-2018-4366 — чтение за границами при обработке видео, возникающее только на Mac.

CVE-2018-4367 — повреждение стека в iOS и Mac. Перед канарейкой стека в затронутой функции находится довольно много переменных, и несколько сбоев фаззинга из-за этой ошибки приводили к нарушениям сегментации, а не к сбоям stack_chk, поэтому она, вероятно, эксплуатируема.

CVE-2018-4384 — повреждение кучи ядра при обработке видео в iOS. Вероятно, оно похоже на эту уязвимость, найденную Адамом Доненфельдом из Zimperium.

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

В части 3 мы рассмотрим видеозвонки WhatsApp.

Исходный код PJSIP открыт, поэтому найти его в двоичном файле WhatsApp для Android (libwhatsapp.so) было легко. PJSIP использует открытую библиотеку libsrtp, и я начала с открытия файла в IDA и поиска строки srtp_protect — имени функции шифрования libsrtp. Поиск привёл к записи журнала, создаваемой функцией, похожей на srtp_protect. В двоичном файле была только одна вызывавшая её функция, незадолго до этого вызывавшая memcpy. Несколько журнальных записей перед вызовом содержали имя файла srtp_transport.c, существующего в репозитории PJSIP. В журнале WhatsApp вызываемая функция называется transport_send_rtp2, тогда как в исходном коде PJSIP есть только transport_send_rtp. Но она похожа на вызывающую srtp_protect функцию WhatsApp: до и после memcpy выполняется то же число вызовов. Если код WhatsApp представляет собой вариант этого кода, memcpy копирует весь незашифрованный пакет непосредственно перед шифрованием.

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

Сначала я написала на ассемблере функцию, загружавшую библиотеку из файловой системы через dlopen, получавшую символ вызовом dlsym, а затем вызывавшую функцию библиотеки. Frida очень помогла с отладкой: она перехватывала вызовы dlopen и dlsym, позволяя убедиться в их правильности. Я перезаписала этой функцией одну из функций перекодировщика GIF в WhatsApp, поскольку она используется только при отправке текстовых сообщений, чего я не собиралась делать в изменённой версии. Затем перенаправила вызов memcpy на эту функцию вместо memcpy, используя сетевой калькулятор переходов ARM.

Функция загрузки библиотеки

Затем я написала библиотеку Android с теми же параметрами, что у memcpy, которая не просто копировала буфер, а сначала подвергала его фаззингу. Библиотеку я поместила в файловую систему, откуда её загружала dlopen, и попробовала выполнить звонок WhatsApp. Видео выглядело подвергнутым фаззингу, и примерно через пятнадцать минут произошёл сбой.

Настройка воспроизведения

Для воспроизведения пакетов я добавила в библиотеку журналирование: каждый изменённый буфер сохранялся в файл. Затем создала вторую библиотеку, которая вместо изменения копировала в буфер зарегистрированные пакеты. Потребовалось немного изменить двоичный файл WhatsApp, поскольку размер записанного пакета обычно не совпадает с размером отправляемого. Я переделала перехваченную memcpy, чтобы длина передавалась по ссылке, а не по значению, и библиотека заменяла её длиной записанного пакета. В результате при вызове srtp_protect использовалась правильная длина. К счастью, пакет копируется в буфер фиксированного размера, поэтому корректный пакет не может переполнить его. Такой шаблон часто встречается при обработке RTP и повышает производительность за счёт сокращения числа проверок длины. Он также помог изменить FaceTime для воспроизведения пакетов разных размеров, как описано в предыдущей статье.

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

Результаты

С помощью этой схемы я зарегистрировала в WhatsApp одну ошибку повреждения кучи — CVE-2018-6344. Впоследствии её исправили. После исправления дальнейший фаззинг не выявил сбоев, влияющих на безопасность, и мы перешли к другим методам. В части 4 будут описаны остальные, неудачные попытки найти уязвимости WhatsApp.

WhatsApp реализует сигнализацию с помощью серии сообщений WhatsApp. Если открыть libwhatsapp.so в IDA, можно увидеть несколько нативных вызовов, обрабатывающих входящие сообщения сигнализации.

После извлечения APK WhatsApp с помощью apktool видно, что эти нативные функции вызываются из цикла в классе com.whatsapp.voipcalling.Voip. Судя по smali, сообщения сигнализации передаются как обычные сообщения WhatsApp через сервер WhatsApp, а этот цикл обрабатывает входящие сообщения.

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

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

Единственный ключ шифрования почти не оставляет возможностей вызвать ошибку искажёнными данными. На всякий случай я пробовала увеличивать и уменьшать его длину, но получила лишь неэксплуатируемые ошибки нулевого указателя. Поэтому я перешла к сообщениям, зашифрованным между узлом и сервером. Цикл Voip в smali, по-видимому, работает так: устройство получает входящее сообщение, десериализует его и, если тип подходит, передаёт в цикл обмена сообщениями. Затем из сообщения читаются некоторые свойства, и в зависимости от типа оно передаётся функции обработки. Та читает дополнительные свойства и вызывает один из перечисленных выше нативных методов, передавая свойства как параметры. У большинства этих функций более 20 параметров.

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

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

В smali APK я нашла класс com.whatsapp.voipcalling.VoiceService$DefaultSignalingCallback с несколькими методами вроде sendOffer и sendAccept, которые, судя по всему, отправляют сообщения, обрабатываемые нативными вызовами. Я изменила sendOffer так, чтобы вместо обычной отправки он вызывал другие методы, например sendAccept. Эксперимент показал, что цикл Voip обрабатывает любой тип сигнала независимо от того, был ли принят вызов. Нативные методы разбирают параметры, обрабатывают их, помещают результат в буфер, а затем вызывают единый метод обработки буфера. Только на этом этапе обработка прекращается, если сообщение имеет неподходящий тип.

Затем я изучила все перечисленные методы в IDA. Код был написан очень консервативно, и большинство необходимых проверок выполнялось. Однако несколько мест показались потенциально ошибочными и требовали дальнейшего исследования. Изменять параметры вызовов в com.whatsapp.voipcalling.VoiceService$DefaultSignalingCallback было слишком медленно для нужного количества тестов, поэтому я стала искать другой способ менять сообщения.

В идеале мне хотелось передавать зашифрованные между узлом и сервером сообщения на свой сервер до отправки, чтобы просматривать и изменять их. Я искала в smali APK WhatsApp место после сериализации, но до шифрования, куда можно добавить smali-функцию отправки и изменения пакетов. Это оказалось довольно сложно и заняло много времени. В итоге я вставила свой smali-код в каждый метод пакетов com.whatsapp.protocol и com.whatsapp.messaging, записывавший данные в ByteArrayOutputStream, не связанный с файлом, — всего примерно в десять методов — и стала смотреть, откуда он вызывается. Определив нужное место, я исправила класс так, чтобы каждый массив байтов, записываемый из потока, отправлялся на мой сервер, а остальные вызовы удалила. (Для тех, кто повторяет исследование: изменённый мной smali-файл содержал строку «Double byte dictionary token out of range», а два изменённых метода вызывали toByteArray и завершались обращением к интерфейсу протокола.) На сервер поступал достаточно полный набор сообщений WhatsApp, и содержимое сообщений сигнализации соответствовало ожиданиям.

Сообщения WhatsApp используют сжатый формат XMPP. Для обратной разработки протокола написано много парсеров, но лучше всего у меня работал парсер whatsapp-reveng. Правда, для корректной работы пришлось заменить токены в whatsapp_defines.py списком, извлечённым из APK. После этого стало проще понимать содержимое каждого пакета, отправленного на сервер.

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

Эти дополнительные проверки не позволили нескольким подозрительным местам стать настоящими проблемами. Например, функция, вызываемая из Java_com_whatsapp_voipcalling_Voip_nativeHandleCallOffer, принимает массив массивов байтов, массив целых чисел и массив логических значений. На их основе она создаёт кандидатов для вызова. Перед циклом, использующим значения обоих массивов, функция проверяет, совпадают ли длины массива массивов байтов и массива целых чисел, но не делает такой же проверки для массива логических значений. Я предположила, что возможен выход за границы, однако целые числа и логические значения сериализуются в виде вектора пар <int,bool>, из которого затем копируются массивы. Поэтому отправить массивы разной длины невозможно.

Особенно тревожно выглядело поле voip_options сообщения. Оно никогда не отправляется исходным устройством, а добавляется сервером перед пересылкой принимающему устройству. Это буфер в формате JSON, обрабатываемый принимающим устройством и содержащий десятки параметров конфигурации.

Пример voip_options (сокращён)

Если один узел мог бы отправить параметр voip_options другому, это открыло бы обширную поверхность атаки, включая JSON-парсер и обработку параметров. Поскольку параметр почти всегда появляется в предложении вызова, я попыталась добавить его в такое предложение, но сервер WhatsApp отклонил сообщение с ошибкой 403. Из бинарного файла следовало, что ещё три типа сигналов во входящем вызове могут принимать voip_options. Сервер принимал Java_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferAccept и Java_com_whatsapp_voipcalling_Voip_nativeHandleCallVideoChanged с параметром voip_options, но удалял его перед отправкой сообщения другому узлу. Однако параметр voip_options, прикреплённый к сообщению Java_com_whatsapp_voipcalling_Voip_nativeHandleCallGroupInfo, пересылался на другое устройство. Я подтвердила это, отправив искажённый JSON и увидев ошибку в журнале принимающего устройства.

WhatsApp обрабатывает параметр voip_options в три этапа. Сначала JSON разбирается в дерево. Затем дерево преобразуется в map, чтобы свойства JSON-объектов можно было эффективно искать, несмотря на их количество. Наконец, WhatsApp перебирает map, находит конкретные параметры и обрабатывает их, обычно копируя в область памяти, где они задают значение, относящееся к совершаемому вызову.

Начав с JSON-парсера, я быстро определила, что это парсер JSON из PJSIP. Я скомпилировала и фаззила его, но нашла лишь одну незначительную ошибку чтения за границами.

Затем я исследовала преобразование дерева JSON, возвращённого парсером, в map. Эта map — очень эффективная структура: хеш-таблица с алгоритмом FarmHash, спроектированная так, чтобы целиком храниться в одном блоке памяти, даже если JSON-объекты глубоко вложены. Я просмотрела множество проектов с открытым исходным кодом и похожими структурами, но не нашла аналога. Я очень подробно изучила создание этой структуры, особенно искала смешение типов и ошибки при расширении блока памяти, но проблем не обнаружила.

Я также исследовала функции, перебирающие map и обрабатывающие отдельные параметры. Они чрезвычайно длинные и, вероятно, созданы инструментом генерации кода вроде bison. В основном функции копируют параметры в статические области памяти, после чего проследить их становится трудно. Ошибок здесь я тоже не нашла. Помимо просмотра имён параметров и поиска значений, способных вызвать проблемы, я не анализировала, как именно используются извлечённые из JSON значения. Особенно перспективным казался параметр A/B-теста setup_video_stream_before_accept. Я надеялась, что он позволит устройству принимать RTP до ответа на вызов и тем самым сделает ошибки RTP не требующими взаимодействия, но добиться этого не удалось.

При исследовании кода стало трудно проверять его работу без возможности отладки. Поскольку WhatsApp поставляет для Android библиотеку x86, я задумалась, нельзя ли запустить JSON-парсер в Linux.

Тэвис Орманди создал инструмент, который загружает библиотеку libwhatsapp.so в Linux и запускает нативные функции, не зависящие от JVM. Он изменяет секцию ELF .dynamic, удаляя ненужные зависимости путём замены тегов DT_NEEDED на DT_DEBUG. Также потребовалось удалить конструкторы и деструкторы, обнулив DT_FINI_ARRAYSZ и DT_INIT_ARRAYSZ. После этих изменений библиотеку можно загрузить обычным вызовом dlopen() и использовать dlsym() и dlclose().

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

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

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

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

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

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

Техническая статья

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

Это было полезно всем.

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

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

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

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

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

В академических исследованиях несколько интересных работ (CCS '16, CCS '17) предложили сложные методы машинного обучения, объединяющие embeddings кода с приближённым поиском ближайших соседей. Они вычисляют представление кода в R^n, а затем ищут соседние точки для выбора подходящих кандидатов. Эти подходы выглядят мощными и изощрёнными, но публичных реализаций нет и практики их не приняли. В прикладной области реальные решения строились на алгоритмах, ориентированных на CFG, например MACHOC, однако они неустойчивы к структурным изменениям и не позволяют «обучать» расстояния. Недавно на SSTIC '18 был представлен подход на основе нейронной сети, авторы которого пообещали опубликовать код в ближайшие месяцы.

В этой статье описывается FunctionSimSearch — набор инструментов C++ под лицензией Apache с привязками Python, предоставляющий три возможности:

1. Эффективную реализацию хеш-функции на основе SimHash, вычисляющей по дизассемблированным функциям 128-битный хеш с сохранением сходства. Расстояние между двумя функциями определяется простым вычислением расстояния Хэмминга между хешами, что на x64 сводится к двум инструкциям XOR и двум POPCNT.

2. Эффективный поисковый индекс для приближённого поиска ближайших соседей среди 128-битных хешей.

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

Необходимость качественного нечёткого сопоставления

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

(Код unrar из Visual Studio 2015 и код с оптимизацией O1 из gcc 6.4.0)

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

Алгоритм SimHash и его возможности

SimHash был представлен в работе Мозеса Чарикара, изначально в контексте дедупликации веб-страниц. Он относится к семейству алгоритмов и концепций locality-sensitive hashing, к которому мы ещё вернёмся.

Алгоритм сворачивает набор значений в хеш так, что расстояние Хэмминга между двумя хешами приближённо отражает сходство исходных наборов. Это позволяет оценивать сходство двух наборов чрезвычайно быстро — всего одной операцией XOR и одной POPCOUNT.

Как он работает? Получив на вход набор признаков, каждый из которых сам является случайным 128-битным вектором — если это не так, его нужно хешировать, — вычисляем итоговый хеш следующим образом:

1. Инициализируем 128-элементный вектор значений с плавающей точкой нулями.

2. Для каждого признака входного набора:

• Если бит n признака равен 0, вычитаем 1 из n-го значения с плавающей точкой.

• Если бит n признака равен 1, прибавляем 1 к n-му значению с плавающей точкой.

3. Преобразуем вектор float в 128-битный вектор, заменяя положительные значения единицами, а отрицательные — нулями.

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

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

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

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

Простой приближённый поиск ближайших соседей для хешей

Имея способ вычислить сохраняющий сходство хеш входной функции, как искать «наиболее похожий» хеш в нетривиально большом корпусе? Ответ заключается во втором применении locality-sensitive hashing. Если построить семейство хеш-функций так, чтобы вероятность попадания двух близких точек в одну корзину была выше вероятности такого совпадения для далёких точек, можно создать сравнительно эффективный поиск ближайших соседей: использовать k различных функций семейства, чтобы сопоставить входные данные корзинам кандидатов, а затем обработать кандидатов.

Случайные биты как locality-sensitive хеши

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

Выбор структур данных

В основе лежит упорядоченная коллекция кортежей следующего вида:

Двоичный поиск с кортежем

даёт корзину хешей для заданного индекса перестановки и входного значения. Мы выполняем k таких поисков и добавляем все элементы каждой корзины в список кандидатов. Затем вычисляется расстояние Хэмминга между каждым кандидатом и входным хешем, после чего результаты возвращаются в порядке этого расстояния. Максимально эффективная по памяти и кэшу версия использовала бы обычный отсортированный плоский массив или vector таких кортежей. Для наших целей и эффективной вставки существующий код C++ использует эквивалент контейнера std::set, сделанный постоянным посредством файла, отображённого в память.

Обучение SimHash по примерам

Один недостаток описанного подхода очевиден сразу: все признаки входного набора считаются одинаково важными. В действительности их важность сильно различается. К счастью, значимость отдельных признаков легко включить в вычисление SimHash: вместо прибавления +1 или -1 к вектору float можно прибавлять или вычитать вес конкретного признака.

Но как вывести хорошие веса из обучающих данных? Можно ли автоматически «узнать», какие признаки сохраняются при смене компилятора и обладают предсказательной силой?

Принцип дешёвого градиента

Рабочая лошадка современного машинного обучения — автоматическое дифференцирование. Упрощённо оно реализует «принцип дешёвого градиента»: «если можно вычислить функцию из R^n в R, то с умеренными накладными расходами можно вычислить и её градиент». Значит, если задать функцию потерь с нашими весами, можно попытаться минимизировать её. Гарантий сходимости не будет, но, скорее всего, веса удастся обучить по примерам.

Итак, нам нужны размеченные данные — в идеале пары функций с метками «одинаковые» или «разные» — и хорошая функция потерь.

Выбор функции потерь для расстояния SimHash

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

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

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

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

Начнём с простой сглаженной ступенчатой функции:

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

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

Генерация обучающих данных

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

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

Реальные проблемы: символы

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

Печальное решение проблемы PDB — «сдаться»: кодовая база ожидает, что информация PDB уже выгружена в текстовый файл. Столь же печальное решение проблемы надёжной сборки одной кодовой базы в Visual Studio и GCC — тоже «сдаться»: обеспечить сборку должен пользователь FunctionSimSearch. Дополнительные трудности создают разные соглашения декорирования имён C++ и специфичные для компиляторов имена функций. Небольшой костыльный инструмент удаляет из символов сведения о типах и пытается унифицировать нотацию GCC/Clang и Visual Studio.

Реальные проблемы: надёжное построение CFG и загрязнённые наборы данных

Получать CFG функций должно быть просто. На практике ни один из проверенных дизассемблеров не разбирает операторы switch корректно для разных компиляторов и платформ: функции обрезаются, базовые блоки назначаются неверно и так далее. Особенно плохи результаты для бинарных файлов GCC, скомпилированных с -fPIC или -fPIE, которые из-за ASLR используются по умолчанию в современных Linux-системах.

В результате загрязняются и обучающие данные, и поисковые индексы, что приводит к ложноположительным и ложноотрицательным результатам и общему разочарованию. Идеальным исправлением был бы более надёжный дизассемблер, но на практике приходится тщательно исследовать крайние расхождения размеров функций, которые должны совпадать, и компилировать обучающие примеры без PIC и PIE. Полезный набор флагов сборки: -fno-pie -fno-PIE -fno-pic -fno-PIC.

Генерация данных на практике

На практике обучающие данные можно создать так:

Скрипт разбирает все найденные файлы ELF и PE в каталогах ./testdata/ELF и ./testdata/PE. Для ELF-файлов с отладочной информацией DWARF он извлекает имена нужных функций с помощью objdump. Для PE-файлов скрипт ожидает рядом с каждым исполняемым файлом текстовый файл <executable_filename>.debugdump с выводом примера DIA2Dump, входящего в Visual Studio.

Создаются следующие файлы:

Каждому исполняемому файлу назначается идентификатор из первых 64 бит его SHA-256. Запись извлечённого символа имеет следующий вид:

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

Файлы attract.txt и repulse.txt содержат пары этих идентификаторов функций:

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

Два способа разделить обучающие и проверочные данные

Почему код создаёт каталоги training_data_seen и training_data_unseen? Потому что есть два разных вопроса:

1. Улучшает ли обучение способность обнаруживать варианты функции, на которой проводилось обучение?

2. Улучшает ли обучение способность обнаруживать варианты функции, если ни одной версии этой функции не было в обучающих данных?

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

Проблемы реализации обучения

Стандартными отраслевыми инструментами машинного обучения служат библиотеки вроде TensorFlow или специализированные языки вроде Julia с пакетами AutoDiff. Они обеспечивают автоматическое распараллеливание и перенос вычислений на GPU. К сожалению, я очень упрям: мне хотелось работать на C++, свести зависимости к минимуму и задать функцию потерь непосредственно на C++. Поэтому я выбрал библиотеку C++ SPII, позволяющую минимизировать произвольную функцию C++.

SPII вычисляет целевую функцию и её производные и передаёт их в L-BFGS, квазиньютоновский оптимизатор с ограниченной памятью. Модель программирования приятно прямолинейна: представить вектор весов как параметры, вычислить сумму потерь притяжения и отталкивания и позволить оптимизатору обновлять параметры. Цена существенна: реализация работает только на CPU, каждая итерация проходит по очень большому набору пар, и оптимизация остаётся мучительно медленной даже на многоядерной машине. В конечном итоге её следует заменить реализацией для GPU.

Запуск процесса обучения

Когда обучающие данные готовы, запустить процесс просто:

Через несколько дней процесс выполнит 500 итераций L-BFGS, записывая снимки каждые 20 шагов — от 20.snapshot до 480.snapshot. Каждый снимок можно оценить на виденном проверочном наборе:

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

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

Интерпретация результатов обучения

Результат можно понять несколькими способами:

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

2. Использовать метрики информационного поиска, например площадь под ROC-кривой.

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

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

Визуализация с помощью t-SNE

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

Создадим два поисковых индекса: один с обученными весами признаков, другой — с единичными:

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

Анализ TPR, FPR, IRR и ROC-кривой

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

В репозитории есть Python-скрипт для генерации данных ROC. Ему нужны символы всех элементов поискового индекса, текстовая выгрузка индекса и доступ к самому индексу:

Скрипт выводит семь столбцов: порог расстояния; TPR и FPR точного поиска; TPR и FPR приближённого поиска; проценты нерелевантных результатов точного и приближённого поиска. «Точный» означает сравнение запроса с каждым хешем в индексе, а «приближённый» — получение кандидатов через корзины locality-sensitive хешей. Сравнение двух пар кривых отделяет ошибки обученного представления от кандидатов, пропущенных индексом.

Для необученных результатов TPR выше 50% требует принять около 20% нерелевантных результатов при пороге примерно 25 бит. Повышение порога до 35 бит увеличивает TPR приблизительно до 55%, но половина возвращаемых результатов становится нерелевантной.

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

Обобщается ли результат на функции вне выборки?

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

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

Практический поиск Использование FunctionSimSearch из любого инструмента обратной разработки с Python

Инструменты командной строки в основном используют для дизассемблирования DynInst, однако специалисты по обратной разработке работают с поразительным разнообразием инструментов: IDA, Radare, Binary Ninja, Miasm и другими. Нативная интеграция с каждым потребовала бы значительных усилий, поэтому FunctionSimSearch предоставляет привязки Python. Один API можно использовать в любом инструменте со встроенным Python.

Установим модуль в окружение Python текущего пользователя:

Простейший API использует JSON-описания графов потока:

В результате получается кортеж Python с хешем функции. Формат входного графа выглядит так:

Подробности приведены в IDA-плагине на Python. Он регистрирует горячие клавиши для сохранения или поиска текущей функции, экспорта всей IDB и сопоставления всех функций дизассемблированного файла с индексом. Плагин с похожими возможностями доступен для Binary Ninja.

Поиск кода UnRAR в mpengine.dll

В первом примере наполним индекс символами UnRAR и поищем узнаваемые функции в mpengine.dll от Microsoft:

После этого откроем mpengine.dll в IDA, загрузим ida_example.py и нажмём Shift-M. В окне сообщений появятся примерно такие результаты:

Рассмотрим несколько результатов подробнее. Первый утверждает, что найдена memcpy_s с совпадением 125 из 128 бит.

За исключением нескольких небольших изменений на уровне инструкций, функции явно одинаковы, а структура CFG осталась идентичной.

Следующий результат заявляет о варианте ppmii::ModelPPM::RestartModelRare с совпадением 108 из 128 бит. Дизассемблированный код и смещения структур значительно изменились, но общий CFG остаётся узнаваемым:

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

Следующий пример — гораздо более крупная функция RarVM::ExecuteCode с совпадением 106 из 128 бит.

Здесь граф значительно изменился, но несколько подграфов сохранились. Код также содержит магические константы вроде 0x17D7840 и 0x36, влияющие на хеш. Это нетривиальная находка.

Ни одна демонстрация поиска не обходится без ложноположительного результата. Поиск сообщает об уверенном совпадении RarTime::operator== — 125 из 128 бит:

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

Поиск кода libtiff в Adobe Reader

Хорошо известно, что в прошлом Adobe Reader страдал из-за устаревших версий libtiff. Поэтому поиск в AcroForm.dll должен находить хорошие совпадения libtiff, а неудача поставила бы метод под сомнение. Наполнив базу несколькими сборками libtiff и запустив плагин, мы получаем десятки результатов с высокой вероятностью совпадения. По сравнению с mpengine.dll копия в AcroForm.dll меньше отклонилась от upstream.

Поиск кода libtiff во всех моих DLL Windows

Искать код, о наличии которого уже известно, не слишком интересно. А что, если поискать следы libtiff на всём диске Windows 10? Нам понадобятся:

• Каталог с libtiff, скомпилированной несколькими версиями Visual Studio с разными настройками компилятора.

• Отладочная информация из PDB в формате, который может разобрать инструментарий. Текущая реализация ожидает рядом с каждым PDB файл .debugdump, созданный перенаправлением вывода инструмента DIA2Dump от Microsoft.

Создадим и наполним индекс:

Создадим метаданные символов поискового индекса:

Затем просканируем DLL:

В выводе есть совпадения в нескольких бинарных файлах Adobe и, что интереснее, в SysWOW64/WindowsCodecs.dll из Windows:

Если загрузить WindowsCodecs.dll и наиболее подходящую сборку libtiff в IDA, получатся следующие графы:

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

Более подробный анализ показывает, что WindowsCodecs.dll содержит значительно изменённое ответвление libtiff 3.9.5. Мы не исследовали, как Microsoft переносит исправления безопасности и надёжности из upstream. Поскольку libtiff компонует libjpeg, неудивительно, что та же DLL содержит и изменённое ответвление libjpeg.

Итоги, будущие направления и следующие шаги

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

Полученные уроки Поисковый индекс против линейного прохода: современные CPU быстро выполняют XOR

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

Алгоритмическая точка безубыточности индекса locality-sensitive hashing достигается лишь далеко за несколькими сотнями миллионов хешей, и неясно, у скольких пользователей будут настолько крупные корпуса. Умный поисковый индекс может оказаться избыточно сложным: линейный проход проще и эффективнее по объёму хранения.

Конкуренция с простым поиском строк

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

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

Задача по-прежнему сложна

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

Можно ли обучить embeddings из дизассемблированного кода в пространство Хэмминга, существенно превосходящие простую линейную модель? Какой вычислительной ценой?

Будущие направления и следующие шаги

Исследование можно развивать в нескольких направлениях:

1. Перенести обучение в среду с поддержкой GPU. Переписать код машинного обучения на TensorFlow, Julia или другую среду, способную эффективно работать на GPU. Текущая реализация C++ требует нескольких дней даже на 56-ядерном сервере.

2. Заменить L-BFGS вариантами SGD. L-BFGS плохо масштабируется с ростом обучающих данных, поэтому редко используется в современном крупномасштабном обучении.

3. Обучение по тройкам и четвёркам. Современные методы обучения embeddings используют целевые функции на основе троек. Для поиска по сходству это интуитивно разумно и должно поддерживаться.

4. Улучшить признаки. Текущие признаки ограничены кортежами мнемоник, graphlet и крупными константами, не делящимися на четыре. Операнды, смещения структур, строки и другая ценная информация игнорируются.

5. Эксперименты с графовыми нейронными сетями. Современные методы обучения на графах способны изучать по примерам простые графовые алгоритмы. Модель из CCS '17 показывает перспективность направления.

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

7. Заменить дерево ANN плоским массивом. Для пользователей с менее чем 100 миллионами хешей линейное сканирование, вероятно, превзойдёт более сложную LSH-структуру с перестановками битов и потребует меньше места.

Конец — пока

Вопросы, рекомендации и, в идеале, pull request можно направлять авторам через соответствующий репозиторий GitHub здесь.

В статье рассматриваются два вопроса. Насколько легко обнаруживать новые уязвимости VBScript, несмотря на всю работу Microsoft и сообщества безопасности? И насколько надёжны политики Windows, призванные остановить их эксплуатацию?

Ещё больше уязвимостей VBScript

Наш подход был прост. Мы взяли опубликованный грамматический фаззер Domato и написали грамматику, описывающую встроенные функции VBScript, callback и другие распространённые конструкции. Ранее тот же подход использовался для поиска уязвимостей JScript в статье aPAColypse now. Грамматика и генератор VBScript доступны в репозитории Domato.

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

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

Более подробный анализ опубликован Trend Micro, но ключевая строка такова:

Сначала вычисляется левая часть и определяется адрес cls.array(2). Затем вычисляется правая. Поскольку cls — объект MyClass с getter свойства по умолчанию, это вызывает callback. Callback изменяет размер массива, делая ранее вычисленный адрес недействительным и оставляя его указывать в освобождённую память. Поэтому присваивание записывает данные в освобождённую память.

Сравним этот пример с PoC нашей первой проблемы:

Уязвимость вызывает строка:

Снова первой вычисляется левая часть и определяется адрес dict.Item("foo"). Затем присваивается новое значение, но сначала нужно очистить старое. Поскольку старое значение является объектом MyClass, его очистка вызывает Class_Terminate(), который опустошает dict. Вычисленный для левой части адрес теперь указывает в освобождённую память.

Оба случая следуют одному шаблону:

1. Вычислить адрес переменной-члена в объекте-контейнере.

2. Присвоить ей значение.

3. Присваивание вызывает callback, освобождающий хранилище контейнера.

4. Присваивание записывает данные в освобождённую память.

Есть два отличия: в одном случае используется массив, в другом — словарь; в одном вызывается getter свойства по умолчанию, в другом — Class_Terminate. Это сходство может объяснять, почему вариант независимо обнаружили исследователь, работавший с Zero Day Initiative компании Trend Micro, и Юки Чен. Автор эксплуатировавшегося в реальных атаках нулевого дня также мог знать о нём.

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

Filter проходит по массиву и возвращает другой массив с элементами, соответствующими заданной подстроке — здесь "a". Один элемент входного массива является объектом с getter свойства по умолчанию, вызывающим callback, который изменяет размер входного массива. Вернувшись в Filter, код читает переменные за границами.

Реализация пыталась предотвратить это, проверяя на каждой итерации, что размер массива не меньше количества совпавших объектов. Проверка не учитывала элементы массива, не соответствующие подстроке, например элементы "b" из PoC.

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

Третья ошибка находится в коде, который уже значительно изменяли для исправления CVE-2018-8174 и вариантов, найденных Qihoo 360 Vulcan Team. Возможно, она даже появилась при исправлении предыдущей проблемы. Фаззер впервые обнаружил её как разыменование NULL-указателя:

Ошибка развивается следующим образом:

1. Создаётся массив a; его тип теперь — массив.

2. В единственный элемент помещается объект class2.

3. Erase a удаляет массив и очищает его элементы.

4. Очистка объекта вызывает его пользовательский деструктор.

5. Callback превращает a в объект class1; теперь его тип — объект.

6. Перед возвратом Erase устанавливает значение a в NULL.

7. Переменная имеет тип объекта и значение NULL, что при использовании может вызвать разыменование NULL-указателя.

На шаге 5 также увеличивается счётчик ссылок объекта class1. Позже a устанавливается в NULL без уменьшения счётчика. Сценарий завершается с объектом, счётчик ссылок которого равен единице, но ни одна переменная на него не указывает: произошла утечка ссылки. Её можно усилить:

Код увеличивает счётчик ссылок c до 1000, хотя реальную ссылку содержит всего одна переменная. Поскольку в VBScript счётчики ссылок являются 32-битными целыми числами, достаточное количество увеличений переполнит счётчик и освободит объект, пока ссылки на него ещё существуют.

Пользовательские классы VBScript защищены от переполнения счётчика ссылок, но встроенные классы вроде RegExp — нет. Если заменить class1 на RegExp, счётчик в конце концов переполнится. Однако каждое увеличение требует callback, поэтому эксплуатация может занять несколько часов и зависит от того, оставит ли жертва вкладку или окно открытым. Тем не менее это полезная демонстрация того, как архитектура VBScript затрудняет устранение ошибок времени жизни объектов.

Поиск утечек ссылок

Мы изменили фаззер, чтобы он подсчитывал пользовательские объекты. Конструктор увеличивал счётчик, а деструктор уменьшал. Если после завершения примера и очистки всех переменных счётчик оставался выше нуля, происходила утечка ссылки.

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

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

Обход политики выполнения VBScript

Решение Microsoft отключить VBScript в зонах Интернета и ограниченных сайтов было шагом в правильном направлении, но политика и её реализация имели слабости.

Во-первых, по умолчанию она применялась только к этим двум зонам. Сценарии в зонах локальной интрасети или доверенных сайтов продолжали работать — предположительно ради компаний, всё ещё зависевших от VBScript. Мы предпочли бы, чтобы VBScript по умолчанию был полностью отключён в движке Internet Explorer.

Во-вторых, Microsoft упустила некоторые пути выполнения Internet Explorer. Браузер поддерживает MSXML, который может запускать VBScript внутри преобразований XSL:

Выполнение VBScript через MSXML не отключалось даже для сайтов зоны Интернета. О проблеме сообщили Microsoft, и к моменту публикации статьи она была исправлена.

Отказ от Internet Explorer как браузера не устраняет проблему полностью. Многие приложения Windows отображают веб-контент с помощью движка Internet Explorer, включая путь Microsoft Office, использованный недавними нулевыми днями. Microsoft отключила создание VBScript в последней версии Office, заблокировав этот популярный вектор, но движок IE встраивают и другие приложения, в том числе сторонние.

Идеи для будущих исследований

Несколько идей осталось на будущее:

• Объединить фаззеры VBScript и JScript, чтобы каждый язык мог обращаться к объектам и функциям другого. Междвижковые callback могут возникать в неожиданных местах.

• Улучшить обнаружение утечек ссылок: запустить IE под отладчиком, останавливаться при создании и удалении объектов и отслеживать адреса живых объектов. Затем память можно сканировать как в этом инструменте в поисках объектов с положительными счётчиками ссылок, на которые больше ничто не ссылается. Page Heap не позволит ошибочно принять устаревшие указатели в освобождённой памяти за ссылки.

• Фаззить другие создаваемые объекты. Многие ошибки опирались на Scripting.Dictionary, который не встроен в VBScript, а создаётся через CreateObject. Другие доступные VBScript объекты могут предоставлять столь же интересные поверхности атаки.

Заключение

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

Microsoft предприняла полезные шаги по сокращению поверхности атаки. Однако в сочетании с обходом политики выполнения и приложениями, использующими движок Internet Explorer для веб-контента, эти ошибки всё ещё могли угрожать пользователям полностью обновлённых систем, соблюдающим лучшие практики. Мы надеемся, что Microsoft более последовательно удалит VBScript из всех значимых для безопасности контекстов.

• CVE-2016-5195 — логическую ошибку Linux, позволявшую записывать данные в общие страницы только для чтения.

• CVE-2018-1038 — ошибку Windows, существовавшую около двух месяцев и неверно устанавливавшую бит разрешений таблицы страниц.

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

Статья посвящена ошибкам, связанным со сбросом translation lookaside buffer (TLB). При удачном выборе момента они могут давать очень сильные примитивы локального повышения привилегий. Среди найденных мной или с моим участием проблем сброса TLB:

• Xen PV XSA-241, «Устаревшая запись TLB из-за гонки при освобождении типа страницы» (CVE-2017-15588).

• Linux: недостаточный shootdown при освобождении кэшей структур страничной организации (отчёт).

• Linux KVM: пропущенный сброс TLB при удалении доступных для записи SPTE (отчёт).

• gVisor: пропущенная инвалидация TLB в управлении памятью sentry (отчёт).

• Linux: mremap() выполняет сброс TLB слишком поздно (отчёт).

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

Введение: TLB и кэши структур страничной организации

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

Точная структура зависит от микроархитектуры. Intel рассматривает организацию TLB в Optimization Reference Manual, Arm — в документации процессоров, а AMD — в руководствах по оптимизации ПО. Кэши структур страничной организации документированы хуже, но архитектурные руководства описывают их существование и правила инвалидации, которым должно следовать ПО.

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

Механизмы инвалидации различаются:

• x86 предоставляет инструкции, инвалидирующие один адрес или всё текущее адресное пространство, с различной обработкой глобальных записей. Для инвалидации на удалённых логических CPU ядро отправляет межпроцессорные прерывания и ждёт завершения — это TLB shootdown.

• Arm предоставляет инструкции межъядерной инвалидации TLB, хотя реализованные вне CPU средства обхода таблиц страниц могут требовать дополнительной синхронизации.

Общий порядок инвалидации таков:

1. Удалить запись таблицы страниц, сохранив ссылку на физическую страницу.

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

3. Только после завершения сброса освободить физическую страницу.

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

На x86 и аналогично на arm64 PTE последнего уровня содержит два бита, которые может устанавливать CPU. Accessed отмечает использование PTE для трансляции. Если бит сброшен, с момента последней записи PTE программой из него не создавалась запись TLB. Dirty отмечает использование PTE для записи; если он сброшен, с момента последнего программного обновления не создавалась доступная для записи запись TLB.

Linux: mremap() сбрасывает TLB слишком поздно Ошибка

Linux защищает состояние управления памятью процесса несколькими блокировками. Семафор чтения/записи mmap_sem в struct mm_struct защищает структуры virtual memory area (VMA). Таблицы страниц более низкого уровня обычно защищены отдельными spinlock каждой таблицы. Такие операции, как mmap(), mremap(), munmap() и обработка page fault, используют и mmap_sem, и блокировки таблиц страниц.

Другие операции над таблицами страниц не удерживают mmap_sem. Например, ftruncate() может уменьшить файл и удалить страницы за его новым концом из всех отображений системы, удерживая только блокировки таблиц страниц.

Системный вызов mremap() перемещает VMA и его PTE по следующей цепочке вызовов:

При эксклюзивно удерживаемом mmap_sem функция move_ptes() приблизительно выполняла следующее:

1. В некоторых случаях брала блокировки обратного отображения.

2. Блокировала старую и новую таблицы страниц.

3. Если direct reclaim отбирал страницы у процесса, сбрасывала TLB.

4. Для каждой непустой исходной PTE:

• Атомарно читала и очищала её через ptep_get_and_clear(); на x86 это превращается в LOCK XCHG.

• Если PTE имела бит Dirty, устанавливала локальный флаг force_flush.

• Записывала PTE в новое отображение.

5. Разблокировала новую таблицу страниц.

6. Если установлен force_flush, сбрасывала старые записи, обработанные на шаге 4.

7. Разблокировала старую таблицу страниц.

8. Освобождала блокировки обратного отображения, если они были взяты.

9. Если force_flush не установлен, сообщала move_page_tables() о необходимости более позднего сброса.

После перебора нескольких таблиц страниц move_page_tables() наконец сбрасывала старый диапазон адресов.

Освобождая старую ссылку таблицы страниц, move_ptes() должна гарантировать отсутствие устаревших записей TLB. Сначала ссылка не уничтожается, а переносится в новую PTE. Пока удерживается блокировка новой таблицы страниц, другая задача не может удалить PTE, поэтому страницу невозможно освободить. Но сразу после разблокировки новой таблицы на шаге 5 другая задача может вступить в гонку с mremap(), удалить новое отображение и освободить последнюю ссылку на страницу. Это происходит задолго до позднего сброса в move_page_tables() и даже немного раньше сброса в ветке force_flush.

В современных ядрах большое окно гонки работает только для PTE без Dirty и даёт чтение use-after-free, но не запись. До коммита 5d1904204c99, вошедшего в Linux 4.9, специальной обработки Dirty PTE не было, и большое окно позволяло записывать после освобождения.

Большинство актуальных дистрибутивов использовало ядра 4.9 или новее; например, в Debian stable применялось 4.9. Исключениями были ядра на основе 3.10 в RHEL и многие устройства Android:

В качестве цели эксплуатации я выбрал Pixel 2.

Блокировки и вытеснение

Linux поддерживает три задаваемые при сборке модели вытеснения кода ядра:

• CONFIG_PREEMPT_NONE: без принудительного вытеснения (сервер).

• CONFIG_PREEMPT_VOLUNTARY: добровольное вытеснение ядра (настольная система).

• CONFIG_PREEMPT: вытесняемое ядро (настольная система с малой задержкой).

Дополнительные модели разрабатывались в наборе патчей реального времени. Pixel 2 использует CONFIG_PREEMPT, поэтому выполнение ядра обычно может быть прервано почти в любом месте, в том числе при удержании mutex или семафора и внутри некоторых критических секций чтения RCU. Spinlock, напротив, подавляет вытеснение.

Атакующему нужно увеличить интервал между освобождением блокировки таблицы страниц в move_ptes() и сбросом TLB в move_page_tables(). В этот период удерживается только mmap_sem, не запрещающий вытеснение. Поэтому планировщик может на несколько миллисекунд снять задачу системного вызова с ядра CPU.

Пространство пользователя может задавать affinity и параметры планировщика задачи. Эксплойт закрепляет несколько принадлежащих ему процессов за одним ядром, назначает задаче mremap() приоритет SCHED_IDLE и размещает на том же ядре задачу с обычным приоритетом, заблокированную в read() канала. Запись в канал в нужный момент пробуждает задачу с обычным приоритетом, которая вытесняет mremap().

Чтобы определить нужный момент, эксплойт злоупотребляет /proc/<pid>/status. Поле VmPTE сообщает объём памяти таблиц страниц. Активный опрос поля показывает выделения таблиц страниц, выполненные mremap().

Распределитель страниц

Linux использует buddy allocator, реализованный в mm/page_alloc.c. Страница порядка n содержит 2^(12+n) байт и имеет такое же выравнивание при нативном размере страницы 4096 байт. Списки свободных страниц разделены по порядку, зоне, типу миграции и, в NUMA-системах, узлу.

К важным зонам относятся:

• ZONE_DMA и ZONE_DMA32 для устройств с ограниченными диапазонами DMA-адресов.

• ZONE_NORMAL для обычной памяти ядра и пространства пользователя, входящей в линейное отображение.

• ZONE_HIGHMEM, отсутствующая на arm64, поскольку её виртуальное адресное пространство способно отобразить всю физическую память.

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

• ZONE_DEVICE для памяти устройств или постоянной памяти.

Типы миграции описывают текущее использование страницы или предпочтительное будущее применение свободной страницы:

• MIGRATE_UNMOVABLE для выделений вроде обычного kmalloc(), которые нельзя просто переместить.

• MIGRATE_MOVABLE для данных вроде пользовательских страниц, которые обычно можно перемещать.

• MIGRATE_RECLAIMABLE для выделений, которые нельзя перемещать, но можно отбросить и создать заново.

• MIGRATE_HIGHATOMIC для специальных резервов выделений высокого порядка.

• MIGRATE_CMA для непрерывных резервов DMA и перемещаемых выделений.

• MIGRATE_ISOLATE для диапазонов, в которых выделение запрещено, например удаляемой «на горячую» памяти.

Свободные списки для каждого CPU, зоны и типа миграции оптимизируют выделения порядка 0. До Linux 4.15 доступ к этим спискам был возможен с обоих концов. Обычные операции добавляют и извлекают с одного конца, отдавая предпочтение горячим в кэше страницам. Освобождение холодных для кэша страниц и некоторые выделения для DMA используют другой конец.

Перед переходом на медленный путь get_page_from_freelist() приблизительно перебирает каждую подходящую зону, сначала проверяя список текущего CPU для предпочтительного типа миграции, затем buddy allocator по возрастающим порядкам. Перемещаемые выделения могут откатиться к MIGRATE_CMA; __rmqueue_fallback() способна украсть блок максимального порядка у другого типа миграции и, возможно, изменить тип блока.

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

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

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

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

1. Вытеснить целевую страницу файла из page cache.

2. Выделить страницы, обеспеченные файлом, например через memfd, и предоставить их как отображение A.

3. Устроить гонку mremap() с ftruncate(), чтобы страницы освободились при сохранении записей TLB для отображения A.

4. Прочитать целевую страницу, заставив ядро выделить одну из освобождённых страниц как новую страницу page cache.

5. Опросить отображение A через устаревшие записи TLB, пока одна из них не покажет содержимое цели. Если раньше произойдёт page fault, начать заново.

6. Через устаревшую трансляцию отображения A многократно перезаписывать целевую страницу.

Теоретически достаточно одной перезаписи. На практике потребовались повторные записи — возможно, из-за одновременного обращения DMA и ПО к памяти или иной детали реализации.

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

Принудительная перезагрузка page cache

Первый шаг — вытеснить целевую страницу. PoC опирается на работу Another Flip in the Wall of Rowhammer Defenses, где обеспеченные файлами страницы многократно перемещаются между физическими страницами посредством вытеснения из page cache. Одно из главных наблюдений работы: алгоритм замещения Linux отдаёт приоритет вытеснению неисполняемых страниц перед исполняемыми.

Политика замещения страниц Linux благоприятствует исполняемым страницам, обеспеченным файлами. Соответствующая логика в shrink_active_list() и page_check_references() даёт таким страницам ещё один проход по активному списку:

Поэтому эксплойт создаёт давление на память с помощью исполняемых страниц, обеспеченных файлами, чтобы преимущественно вытеснить неисполняемое целевое отображение. Также нужно, чтобы вытесненная страница отсутствовала до явного чтения. Это не гарантировано: в зависимости от наблюдаемого шаблона доступа механизм упреждающего чтения Linux при page fault может загрузить вокруг него до VM_MAX_READAHEAD, то есть 128 КиБ. filemap_fault() реализует это поведение, вызывая do_async_mmap_readahead() или do_sync_mmap_readahead().

Атакующий может отключить упреждающее чтение для собственных обращений, но посторонние процессы способны выполнять код с других страниц той же библиотеки. Поэтому PoC вытесняет цель, затем обращается ко всем остальным страницам через отображение с MADV_RANDOM. Если страница уже резидентна, синхронное упреждающее чтение не выполняется. Если minor fault обнаруживает страницу в кэше без PTE и страница не помечена PG_readahead, асинхронное упреждающее чтение также не выполняется. Предварительная загрузка соседних страниц таким способом уменьшает вероятность того, что другой процесс побочно загрузит цель.

Выбор целевой страницы

Эксплойт нацелен на страницу в /system/lib64/libandroid_runtime.so, содержащую com_android_internal_os_Zygote_nativeForkAndSpecialize(). Эта функция выполняется внутри zygote Android при создании процесса приложения. На бездействующем устройстве она должна запускаться редко, оставляя время для вытеснения страницы и гонки, но атакующий может вызвать её по требованию, запустив изолированную службу.

Zygote имеет CAP_SYS_ADMIN и право его использовать. Поскольку его задача — создавать дочерние процессы, превращающиеся в процессы приложений и system_server, он имеет доступ к контекстам SELinux system_server и любого приложения. Повреждение страницы исполняемого кода функции тем самым внедряет код в привилегированный и необычайно мощный процесс.

Чтобы сделать успех заметным, внедрённый код читает свой контекст SELinux и передаёт строку функции sethostname(). Имя устройства затем показывает, что код выполнился в ожидаемом контексте.

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

Эксплойт упакован как приложение. Нажатие run сначала запускает eviction.c для удаления целевой страницы из page cache, затем sched_test.c для победы в гонке и отравления страницы. Если нативный код сообщает, что нашёл и перезаписал цель, Java запускает изолированную TriggerService, принуждая выполнить com_android_internal_os_Zygote_nativeForkAndSpecialize(). Если цель не найдена, приложение начинает попытку заново.

Компонент планировщика координирует следующие потоки:

• idle_worker() работает на ядре 4 с приоритетом SCHED_IDLE и во время атаки переносится на ядро 3.

• spinner() работает на ядре 4 с обычным приоритетом.

• nicer_spinner() работает на ядре 3 с обычным приоритетом.

• read_worker() работает на ядре 5 с обычным приоритетом.

• main() работает на ядре 6 с обычным приоритетом.

Изменения affinity и относительные приоритеты точно управляют моментом вытеснения idle_worker(), пока другие ядра выполняют чтение цели и сопутствующую работу распределителя.

Первый снимок показывает повторные попытки до заметной победы в гонке:

Второй показывает, что эксплойт способен читать через устаревшую запись TLB, но ещё не нашёл и не перезаписал целевую страницу:

Последний снимок показывает успешную эксплуатацию:

Хронология

• 2018-10-12: об ошибке сообщили команде безопасности ядра Linux.

• 2018-10-18: исправление было закоммичено и опубликовано.

• 2018-10-20: выпущены стабильные ядра 4.9.135, 4.14.78 и 4.18.16.

• 2018-10-29: Project Zero опубликовала отчёт.

• 2018-11-10: выпущен upstream backport для 4.4.

• 2018-11-14: Project Zero опубликовала эксплойт.

Изменение upstream-ядра добиралось до пользовательских устройств более двух месяцев. Написание эксплойта заняло гораздо меньше времени.

Заключение

Единого всеобъемлющего вывода нет, но выделяются несколько важных уроков:

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

• При эксплуатации освобождённой физической страницы в Linux нужно учитывать зоны, типы миграции, списки текущего CPU и fallback-поведение распределителя.

• Вытеснение ядра, политика планирования, affinity CPU и наблюдаемая статистика /proc способны превратить узкое окно конкурентности в практическую гонку.

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

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

1. Если служебная функция MIG завершается успешно, она принимает во владение все переданные ей ресурсы.

2. Если она завершается с ошибкой, она не принимает во владение ни один из них.

Это описание не отражает всей сложности объектов ядра, которыми управляет MIG.

Исследование началось с переполнения счётчика ссылок в semaphore_destroy(). Ветка обработки ошибки оставляла semaphore_t с лишней ссылкой. Автоматически сгенерированная обёртка _Xsemaphore_destroy() содержит следующий важный код:

convert_port_to_semaphore() создаёт ссылку на нижележащий semaphore, не потребляя ссылку порта. Если предположить, что сама обёртка ничего не теряет и не освобождает лишнего, semaphore_destroy() должна потреблять ссылку semaphore и при успехе, и при ошибке. Это не следует из распространённого описания MIG двумя правилами.

Возникло два вопроса: каковы полные правила MIG и нарушает ли какой-либо код менее очевидные из них?

Неудачный обмен

Поиск быстро привёл к task_swap_mach_voucher(). Её определение в osfmk/mach/task.defs выглядит так:

Сгенерированная обёртка _Xtask_swap_mach_voucher() по существу выполняет следующее:

Из обёртки можно вывести предполагаемую семантику службы:

1. new_voucher заимствован; служба не должна потреблять его ссылку.

2. Служба владеет входным значением old_voucher и обязана его потребить.

3. При ошибке выходное значение old_voucher должно остаться не принадлежащим обёртке.

4. При успехе служба должна вернуть через old_voucher принадлежащую ей ссылку, которую обёртка преобразует в порт.

Сравним это с похожей на заглушку реализацией XNU 4903.221.2 из osfmk/kern/task.c:

Она нарушает оба требования владения. Реализация перезаписывает принадлежащее ей входное значение in_out_old_voucher, не вызывая ipc_voucher_release(), и тем самым теряет ссылку. Кроме того, она возвращает new_voucher без retain, хотя входная ссылка была заимствована; позже обёртка считает выходное значение принадлежащим ей и потребляет ссылку, которой служба не получала.

Таким образом, функция содержит два примитива подсчёта ссылок. Передача voucher третьим аргументом приводит к утечке ссылки. Передача вторым — к удалению ссылки. В thread_swap_mach_voucher() была похожая утечка, но изменения iOS 12 сделали этот вариант неэксплуатируемым.

О voucher

Mach voucher в ядре являются объектами ipc_voucher_t:

Voucher представляет неизменяемую коллекцию произвольных атрибутов, которую можно передавать между процессами как право отправки в Mach-сообщении. По-видимому, главным клиентом является libdispatch компании Apple.

Здесь важны только iv_refs и iv_port. В iOS 12 iv_refs — 32-битный os_refcnt_t с допустимым диапазоном от 1 до 0x0fffffff. Retain или release voucher за пределами диапазона вызывает панику ядра. iv_port указывает на ipc_port, представляющий voucher пространству пользователя. convert_voucher_to_port() инициализирует его, когда он равен NULL.

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

Это вне строки!

Ошибку можно эксплуатировать несколькими способами. Мой любимый увеличивает указатель на out-of-line Mach-порт, пока тот не начнёт указывать в буферы каналов.

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

Среди структур ядра, хранящих указатели voucher, есть ipc_kmsg.ikm_voucher и thread.ith_voucher. Полем потока управлять проще всего. Установка voucher текущего потока сохраняет указатель, а уязвимость может удалить дополнительную ссылку, которая в норме поддерживает объект в живом состоянии.

Voucher занимают отдельную zalloc-зону ipc.vouchers. Повторно использовать память другим voucher легко, но для объекта другого типа нужен сборщик мусора зон, который вернёт полностью свободную страницу зоны общему распределителю.

Висячий указатель ith_voucher можно задействовать через thread_get_mach_voucher(). Операция выполняет retain voucher и возвращает его Mach-порт. Если iv_port не равен NULL, он разыменовывается. Если равен, convert_voucher_to_port() выделяет новый порт и записывает указатель обратно в висячий объект.

Подходящие замещающие данные предоставляет out-of-line descriptor портов. Получая крупное Mach-сообщение с множеством прав на порты, ядро выделяет массив указателей ipc_port_t. Отправитель выбирает, какие элементы являются настоящими портами, а какие — MACH_PORT_NULL, что позволяет обнулить iv_port в замещающих данных.

Более сложное поле — iv_refs. Размер struct ipc_voucher равен 0x50 байт, а iv_refs находится по смещению 0x8. На little-endian iPhone массив out-of-line-указателей помещает младшие 32 бита адреса одного ipc_port поверх счётчика ссылок. Если они равны нулю или превышают 0x0fffffff, обращение к висячему voucher вызывает панику.

Распределение кучи в новых iOS достаточно предсказуемо для решения задачи. Страницы zalloc выделяются по возрастающим адресам. Разместив базовый порт по подходящему адресу и многократно сославшись на него в out-of-line-массиве, можно превратить младшие биты адреса в допустимое значение iv_refs. Retain висячего voucher увеличит эти младшие биты, а значит, увеличит поддельный указатель порта на единицу.

Рабочая стратегия:

1. Выделить одну страницу Mach voucher.

2. Сохранить целевой voucher в ith_voucher текущего потока и через ошибку удалить добавленную ссылку.

3. Освободить все порты voucher, освободив страницу объектов voucher.

4. Принудительно запустить сборку мусора зон, чтобы пустая страница покинула ipc.vouchers.

5. Повторно выделить страницу как out-of-line-массив, заполненный выбранным базовым портом и NULL-элементами над iv_port.

6. Вызвать thread_get_mach_voucher(). Увеличение счётчика ссылок висячего voucher изменит младшие биты out-of-line-указателя порта.

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

Несбыточные мечты о pipe

На что должен ссылаться изменённый указатель? В идеале — на память, содержимым которой можно полностью управлять, не освобождая и не выделяя заново сам поддельный ipc_port.

Иэн Бир разработал такой приём для эксплойтов multi_path и empty_list с использованием буферов каналов. Настоящий базовый порт размещается в виртуальной памяти ядра непосредственно перед буфером pipe. Увеличение out-of-line-указателя перемещает его с настоящего порта в контролируемые атакующим байты буфера. Получение Mach-сообщения затем даёт пространству пользователя право отправки, объект ipc_port которого в ядре перекрывает буфер pipe. Чтение и запись pipe напрямую читают и записывают хранилище поддельного порта.

tfp0

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

Классический примитив pid_for_task() делает порт похожим на task port. Указатель bsd_info поддельной задачи направляется на читаемую память, а pid_for_task() возвращает значение по смещению p_pid. Это даёт чтение четырёх байт ядра, но самой поддельной задаче нужен известный адрес ядра.

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

Адрес самого буфера pipe выводится из его известного смещения относительно базового порта. Вызов mach_port_request_notification() для поддельного порта добавляет запрос уведомить базовый порт о смерти поддельного. Это заставляет ядро сохранить указатель базового порта в контролируемом атакующим состоянии поддельного порта и раскрывает опорный адрес через pipe.

Зная адрес pipe, можно построить внутри него поддельную kernel task и получить полное чтение и запись ядра. Выделим стабильную память ядра через mach_vm_allocate(), поместим туда новую поддельную kernel task и изменим имя поддельного порта в процессе, чтобы оно ссылалось на постоянный объект. Результат — tfp0, пользовательское право отправки в поддельный kernel task port.

Код эксплойта для iPhone XS, iPhone XR и iPhone 8 доступен как voucher_swap. Исходный код содержит более подробное пошаговое описание метода.

Столкновение ошибок

Я сообщил об уязвимости Apple 6 декабря 2018 года. К 19 декабря Apple уже выпустила бета-версию iOS 12.1.3, сборку 16D5032a, с исправлением. Необычайно быстрая реакция указывала, что Apple уже знала о проблеме.

Позже я узнал, что Цисюнь Чжао (@S0rryMybad) из Qihoo 360 Vulcan Team независимо обнаружил и эксплуатировал ту же ошибку. Он также опубликовал свою стратегию получения tfp0.html). Забавно, что оба исследования начались с semaphore_destroy(), так что и другие исследователи могли пройти тем же путём.

Заключение

В статье рассмотрена проблема Project Zero 1731, уязвимость подсчёта ссылок IPC voucher, вызванная нарушением семантики MIG для объектов inout. При запуске вскоре после свежей загрузки эксплойт работает надёжно и за несколько секунд получает tfp0.

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

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

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

Следующая статья использует этот эксплойт для исследования реализации Pointer Authentication от Apple и разрабатывает способ подделки PAC для указателей, подписанных ключами A, достаточный для произвольных вызовов или выполнения кода ядра.

Строго говоря, Pointer Authentication — функция безопасности, а PAC — код, встроенный в указатель. В обычной речи всю функцию часто называют PAC, и в статье это сокращение используется там, где смысл очевиден.

Дополнительные сведения приведены в whitepaper Qualcomm, слайдах Марка Ратленда с Linux Security Summit, статье Джонатана Корбета на LWN и Arm A64 Instruction Set Architecture.

Хотя ширина указателей составляет 64 бита, развёрнутые системы обычно реализуют гораздо меньшее виртуальное адресное пространство. Pointer Authentication использует оставшиеся биты расширения для усечённого кода 64-битного указателя и 64-битного контекста.

Реализации могут выбирать алгоритм, но Arm рекомендует QARMA — лёгкий настраиваемый блочный шифр, предназначенный для аутентификации указателей. QARMA-64 принимает 128-битный секретный ключ, 64-битный указатель как открытый текст и 64-битный контекст как tweak. Усечённая часть шифротекста становится PAC.

Архитектура определяет пять 128-битных ключей:

• APIAKey и APIBKey подписывают указатели инструкций.

• APDAKey и APDBKey подписывают указатели данных.

• APGAKey — универсальный ключ, используемый PACGA для подписи более крупных данных.

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

Основные семейства инструкций:

• PAC* вычисляет и вставляет PAC. PACIA X8, X9 подписывает указатель в X8 ключом APIAKey с контекстом X9; PACIZA использует нулевой контекст.

• AUT* проверяет подписанный указатель. При успехе восстанавливает биты расширения; при неудаче записывает шаблон ошибки, чтобы разыменование завершилось fault.

• XPAC* удаляет PAC без проверки.

• BLRA*, LDRA* и RETA* объединяют аутентификацию соответственно с переходом, загрузкой и возвратом.

Например, BLRAA X8, X9 проверяет X8 ключом A для инструкций и контекстом X9, затем выполняет переход. LDRAA X8, X9 проверяет указатель данных в X9 с нулевым контекстом и загружает данные через него. RETAB проверяет link register ключом B для инструкций и выполняет возврат.

Известное ограничение: гаджеты подписи

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

Слабости против атакующих ядро

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

Стандартная архитектура предполагает три возможные слабости:

1. Прочитать ключи PAC из памяти ядра.

2. Подписать указатели ядра, выполняя инструкции PAC в пространстве пользователя.

3. Заменить один ключ другим и использовать гаджет для неверного ключа.

Чтение ключей PAC из памяти ядра

PAC устойчив к обычному раскрытию: наблюдение подписанных указателей не раскрывает криптографически стойкий ключ, а EL0 не может читать регистры ключей. Атака на ядро отличается. Похоже, новые устройства iOS не запускали гипервизор на EL2 или secure monitor на EL3, поэтому ядро EL1 должно было само управлять состоянием PAC. Поскольку регистры ключей очищаются при переходе ядра CPU в сон, ключи, по всей видимости, в какой-то момент должны находиться в памяти ядра.

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

Межуровневая подделка PAC

Псевдокод архитектуры принципиально не отличает PACIA на EL0 от PACIA на EL1. Если Apple повторно использовала один ключ на разных exception level, пространство пользователя могло бы напрямую подписать указатель ядра.

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

Межключевая подделка PAC

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

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

Традиционный путь от чтения/записи к выполнению использует iokit_user_client_trap(), описанный Стефаном Эссером в Tales from iOS 6 Exploitation. Подмена vtable IOUserClient позволяет через IOConnectTrap6() вызвать произвольную функцию с количеством аргументов до семи.

На A12 dynamic cast к IOUserClient, vtable user client и вызов getTargetAndTrapForIndex() аутентифицируются. Однако возвращённый IOExternalTrap.func читается без немедленной проверки и при вызове аутентифицируется с нулевым контекстом.

Для атакующего это благоприятно. Легитимному user client, чей getTargetAndTrapForIndex() возвращает IOExternalTrap в доступной для записи памяти, нужен лишь один поддельный указатель функции PACIZA. Поиск в kernelcache обнаружил именно такой класс: IOAudio2DeviceUserClient. Его таблица внешних trap выделяется в куче.

Таким образом, атака может:

1. Открыть соединение IOAudio2DeviceUserClient.

2. Подделать указатель PACIZA на целевую функцию ядра.

3. Перезаписать userClient->traps[0].func.

4. Вызвать IOConnectTrap6().

Это позволяет управлять X1–X6; X0 остаётся объектом, возвращённым как this. Для полного контроля нужна поддельная vtable указателей PACIA и указатель PACDZA на эту таблицу. Но JOP-гаджет может переместить контролируемый аргумент в X0 и перейти к другой контролируемой функции, создавая произвольный четырёхаргументный вызов ядра всего из одной подделки PACIZA.

Анализ PAC на A12

В экспериментах использовался voucher_swap, эксплойт, чтобы получить чтение/запись ядра на iPhone XR с iOS 12.1.1, сборкой 16C50.

Поиск мест установки ключей PAC

IDA не именовала регистры ключей PAC. Поиск в зеркале репозитория LLVM обнаружил такие имена, как APIAKeyLo_EL1, и их кодировки в AArch64SystemOperands.td. Поиск в IDA соответствующей строки операнда #0, c2, c1, #0 нашёл записи в common_start из osfmk/arm64/start.s.

Удивительно, но common_start, похоже, назначала постоянные значения при каждом запуске ядра CPU. Дизассемблированный код это подтвердил. Ключи A и общий ключ задавались только там, а ключи B обновлялись при переключении контекста потока. Эти пути загружали 64-битное значение по смещению 0x458 структуры struct thread, копировали его в обе половины APIBKey и использовали увеличенное на единицу значение для обеих половин APDBKey.

Очевидного кода, меняющего ключи при переходе между EL0 и EL1, не было. Путь переключения контекста ключей B виден в osfmk/arm64/cswitch.s. @ProteasWang независимо перечислил те же места в pac-set-key.md. При буквальном прочтении ядро использовало постоянные, фактически 64-битные ключи A, общие с пространством пользователя. Это нарушило бы основы криптографической практики и сделало межуровневую подделку тривиальной, поэтому видимое программное состояние не могло быть всей реализацией.

Наблюдение за поведением во время работы

Чтобы проверить, действительно ли ключ A постоянный, я записывал глобальный указатель функции PACIZA, sysclk_ops.c_gettime, указывающий на rtclock_gettime(), при 30 загрузках вместе со сдвигом ASLR ядра. Когда две загрузки используют один сдвиг, нижележащий указатель и нулевой контекст идентичны. При детерминированном алгоритме и постоянном ключе подписанные указатели тоже должны совпасть.

Но они не совпадали. Загрузки с одинаковым сдвигом давали разные PAC. При этом память во время работы всё ещё содержала очевидную константу ключа 0xfeedfacefeedfacf, исключая простую подмену литерала ключа при загрузке до блокировки KTRR.

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

Попытки обхода

Неизвестное значение для каждой загрузки помешало пользовательской реализации QARMA. Межуровневая подпись тоже не сработала.

Затем я объединил идеи межуровневой и межключевой атаки: установил seed IB потока равным значению IA ядра и выполнил PACIZB в пространстве пользователя. Менять ключи живого потока опасно: существующие подписанные адреса возврата сразу становятся недействительными. В безопасном эксперименте поток целиком в пространстве пользователя циклически выполнял PACIZB и сохранял результат. Другой поток менял его seed и принудительно снимал с ядра; при возобновлении Switch_context устанавливала новые ключи B, не заставляя цикл вызывать функции или возвращаться.

Подделка всё равно не удалась. Более прямой тест симметрии использовал одинаковые ключи IB и DB и сравнивал PACIZB с PACDZB для одного значения. Результаты не были связаны, показывая, что A12 также нарушает межключевую симметрию.

Теории реализации

Apple явно учитывала атакующих с чтением/записью ядра и усилила архитектурную схему. Одним из объяснений мог быть не обнаруженный secure monitor, перехватывающий записи ключей и переходы между exception level, однако kernelcache не давал признаков его существования.

Более правдоподобная теория: A12 хранит скрытый случайный ключевой материал внутри SoC. Эффективный ключ может объединять скрытое значение для каждой загрузки, видимый ПО регистр ключа, тип операции и текущий exception level. Например, аппаратная часть может хранить десять случайных ключей — по одному для каждой пары EL0/EL1 и IA/IB/DA/DB/GA — и выполнять XOR выбранного скрытого ключа с архитектурным. Такая схема аккуратно разрушает межуровневую и межключевую симметрию и предотвращает программное раскрытие, хотя спящим ядрам CPU потребовалось бы постоянное хранилище скрытого состояния.

Остальная часть исследования исходит из сильнейшей версии этой модели: настоящие случайные ключи недоступны ПО.

Имитация exception level для PAC

Первая PACIA в kernelcache находилась внутри vm_shared_region_slide_page_v3(), которая перебазирует пользовательские образы и должна подписывать пользовательские указатели от их имени. Поскольку A12 разделяет подпись EL0 и EL1, ядру нужен способ запросить поведение EL0.

Пути ядра, выполняющие такую подпись, очищают и восстанавливают бит 0x4 недокументированного регистра S3_4_C15_C0_4 вокруг инструкций PAC. Они также запрещают прерывания и проверяют флаг загрузки. Естественный вывод: этот бит выбирает, ключи какого exception level использовать для PAC — установлен для EL1, очищен для EL0. Пока выбраны ключи EL0, прерывания должны оставаться отключёнными, иначе несвязанная аутентификация ядра может вызвать панику.

Биты включения PAC в SCTLR_EL1

Ранее зарезервированные биты SCTLR_EL1 также, по-видимому, управляли семействами инструкций PAC. Код входа в системный вызов обращался к флагам загрузки и устанавливал биты, не описанные Arm. В открытом XNU в osfmk/arm64/proc_reg.h случайно сохранился SCTLR_PACDB_ENABLED для бита 13.

Вероятное соответствие:

В экспериментах с отладчиком изменялось поле по смещению 0x460 текущего потока, после чего над известными регистрами выполнялись все семейства PAC. До изменения каждая инструкция генерировала код. После него все, кроме PACIB, вели себя как NOP, подтверждая соответствие. Превратить это в эксплойт было трудно из-за дополнительных проверок потоков ядра, но сами биты включения раскрыли ещё одно расширение Apple.

(Не)существование гаджетов подписи

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

Apple удалила очевидные гаджеты из kernelcache. Места PACIA были непригодны или обёрнуты имитацией EL0. Большинство результатов PACIZA не сохранялось. Гаджеты с загрузкой и сохранением обычно сначала проверяли вход через AUTIA, очевидно требуя, чтобы у атакующего уже был действительный указатель.

Четвёртая слабость

Ключевая идея возникла из вопроса: что произойдёт, если PACIZA подпишет недействительный результат неудачного AUTIA?

При ошибке аутентификации AUTIA вставляет код ошибки в биты расширения указателя. Получая недопустимые биты расширения, PACIZA вычисляет PAC для указателя с исправленными битами, а затем намеренно повреждает результат, переворачивая один бит PAC.

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

Полная стратегия подделки ключей A для 16C50 Этап 1: подделка PACIZA

Полезная последовательность находится в sysctl_unregister_oid(). Если создать sysctl_oid, проходящий по нужному пути, функция аутентифицирует и повторно подписывает oid_handler, а затем сохраняет повреждённый результат.

Ни один глобальный указатель PACIZA напрямую не называет эту функцию, но выгружаемые расширения ядра имеют подписанные функции остановки модулей, вызывающие её. Лучшим кандидатом стала l2tp_domain_module_stop() из com.apple.nke.lttp. Она отменяет регистрацию глобального объекта sysctl__net_ppp_l2tp.

Чтобы подписать произвольный указатель:

1. Перезаписать sysctl__net_ppp_l2tp подготовленным объектом с этим указателем в oid_handler.

2. Вызвать l2tp_domain_module_stop() через существующий подписанный указатель функции.

3. Прочитать изменённый oid_handler.

4. Перевернуть бит 62, восстановив настоящее значение PACIZA.

Этап 2: подделка PACIA/PACDA

Один примитив PACIZA позволяет вызывать второй гаджет подписи. Внутренняя функция по адресу sub_FFFFFFF007B66C48 содержит подходящие инструкции PACIA и PACDA до создания stack frame, поэтому выполнение можно безопасно начать с середины, а затем нормально вернуться.

Гаджет ожидает указатель и контекст в X9 и X10, тогда как примитив iokit_user_client_trap() управляет только X1–X6. Три обфусцированных расширения — FairPlayIOKit, LSKDIOKit и LSKDIOKitMSE — содержат множество неаутентифицированных косвенных переходов. Их обфускация непреднамеренно создаёт богатый набор JOP-гаджетов.

Короткая JOP-программа перемещает контролируемые значения в X2, X9 и X10, затем переходит в последовательность подписи. Вместе с примитивом вызова первого этапа это даёт произвольные подписи PACIA и PACDA и полный обход ключей A.

Хронология

Я передал исходный эксплойт чтения/записи ядра 18 декабря 2018 года, а 30 декабря сообщил о PoC обхода PAC. PoC подделывал произвольные подписи ключей A и вызывал функции ядра с семью аргументами, обеспечивая ту же гибкость, что и на устройствах без PAC.

Apple ответила, что бета-сборка iOS 12.1.3 16D5032a должна смягчить проблему. Эта же сборка исправляла voucher_swap, поэтому прямое тестирование было невозможно, но анализ kernelcache подтвердил исправление гаджета sysctl_unregister_oid(). Бета была выпущена 19 декабря, до отчёта об обходе, что указывало на обнаружение проблемы другим исследователем.

Исправление Apple

Apple изменила пути AUTIA–PACIA так, чтобы при ошибке аутентификации выбирался недействительный аутентифицированный указатель, а не последующий результат PACIZA. Атакующий больше не может получить подпись с одним перевёрнутым битом, если у него ещё нет подделки PACIA для конкретного контекста.

Стратегии полного перебора

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

Наблюдаемые биты расширения показывали маску PAC 0xff7fff8000000000, то есть A12 использует 24-битный PAC — около 16 миллионов вариантов. 256 вызовов l2tp_domain_module_stop() и соответствующей функции запуска занимали около 13,2 мс. Поэтому полный поиск должен занять примерно 15 минут. После нахождения одного значения PACIZA остальная стратегия ключей A остаётся доступной, если не вмешаются другие изменения.

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

Заключение

Реализация Pointer Authentication в A12 от Apple была экспериментально исследована, смоделирована по её отклонениям от Arm и атакована при наличии чтения/записи ядра. Результатом стала полная стратегия подделки ключей A и PoC для iPhone XS с iOS 12.1.2, достаточные для произвольного выполнения в ядре через JOP. Бета-сборка iOS 12.1.3 16D5032a частично смягчила проблему, хотя полный перебор всё ещё может обойти изменение.

PAC остаётся сильной и полезной защитой. Усиление SoC от Apple победило каждую систематическую слабость, выводимую из стандартной архитектуры, вынудив эксплойт зависеть от гаджетов подписи, которые можно исправить программно. Обход был хрупким: он опирался на единственный подходящий IOUserClient, один из очень немногих гаджетов PACIZA и неаутентифицированные JOP-гаджеты, случайно внесённые обфускацией.

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

Мне хотелось понять первопричину, определить, действительно ли патч её устранил, и поискать варианты. Варианты действительно нашлись и приводили к записи за границами стека и кучи в renderer Chrome.

Геометрия для авторов эксплойтов

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

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

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

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

Ошибка

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

Skia считает каждый RRect выпуклым, поэтому вспомогательный класс SkAutoPathBoundsUpdate помечает преобразованный path как kConvex_Convexity. Некоторые алгоритмы рисования корректны только для выпуклых path. Передача им вогнутого path может повредить память — именно это и произошло.

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

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

Точно вычислять выпуклость координат с плавающей точкой чрезвычайно сложно. Convexicator в Skia использует две проверки:

• Обходит path и измеряет изменения направления. Path, постоянно поворачивающий в одну сторону, должен быть выпуклым.

• Проверяет, что он монотонен и по x, и по y.

Две слабости пропускают вогнутые path:

1. Пары точек, квадрат расстояния между которыми теряется при переполнении снизу 32-битного float, то есть расстояния меньше примерно 3.74e-23, игнорируются. Крошечные рёбра вогнутости исчезают из проверки.

2. Допуски в вычислении направления принимают гораздо более крупные вогнутости — в экспериментах около 1e-10, — если path всё ещё проходит обе проверки монотонности.

Path нужны хотя бы несколько более крупных рёбер, чтобы Skia могла определить направление. Линия считается выпуклой, поэтому почти линейный path может содержать крошечные вогнутости, проходить проверки и позднее расширяться.

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

Алгоритм walk_convex_edges

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

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

Вариант 1

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

Skia ожидает, что (1, 1) будет выведено раньше (1, 2) и раньше (2, 1). Здесь последующая область повторно использует координаты y, но содержит меньшие значения x. Представление clip region через длины серий становится неверно упорядоченным.

Предположим, одна строка сканирования clip содержит диапазоны [10, 20] и [0, 2], а рисуемая линия — [15, 16]. SkRegion::Spanerator::next() содержит:

Для первого диапазона clip runs[0] равен 10, и алгоритм нормально продвигается. Для ошибочно упорядоченного второго диапазона условие завершения работает не так, как задумано. Вычисляется left = Max(15, 0) = 15 и right = Min(16, 2) = 2, поэтому left становится больше right.

Значения доходят до:

и в итоге индексируют массивы за границами:

Когда рисуются всего два пикселя, массивы серий выделяются на стеке функцией SkBlitter::blitAntiH2, что приводит к записи за границами стека.

Вызов проблемы в браузере

Нужна следующая последовательность:

1. Получить контроль над SkPath.

2. Заставить Skia вычислить и закэшировать его выпуклость.

3. Преобразовать тот же path и использовать его как заполненный path или clipping path.

Непосредственное двойное рисование path через CanvasRenderingContext2D не работает. Skia копирует path перед применением даже единичного преобразования, что сбрасывает выпуклость копии, а сам Chrome копирует аргументы path.

Однако Chrome записывает операции canvas и воспроизводит их позднее. Во время записи DrawPathOp::CountSlowPaths() проверяет выпуклость исходного path:

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

Первый путь повреждения памяти всё ещё зависит от clipping region без сглаживания, тогда как Chrome сглаживает clipping canvas. Для браузера нужны дополнительные варианты.

Вариант 2

Skia реализует три заполнителя со сглаживанием. SkScan::SAAFillPath, использующий supersampling, следует практически тому же алгоритму обхода рёбер. Он может вызвать SuperBlitter::blitH в неожиданном порядке. Метод передаёт смещение x функции SkAlphaRuns::add; если новый диапазон начинается левее уже выведенного в той же строке сканирования, результат вычитания делает x отрицательным.

Затем SkAlphaRuns::Break пропускает цикл инициализации (while (x > 0)) и доходит до кода, предполагающего, что runs[0] инициализирован:

Неинициализированное n становится смещением массива, приводя к чтению и записи за границами.

Фигура должна последовательно выводить два диапазона для одной координаты y, причём второй должен находиться левее первого. Узкая оранжевая область между рёбрами 3 и 4 обеспечивает этот порядок. Второй диапазон не должен начинаться с x = 0, поэтому ребро 5 останавливается немного внутри изображения. Простое рисование path в Chrome запускает PoC варианта 2.

Вариант 3

Последний path сложнее и самопересекается; его PoC также доступен.

После обработки рёбер 1–4 рёбра 5–8 заставляют повторно посещать строки сканирования и диапазоны x в порядке, который заполнитель выпуклых фигур не способен представить. При использовании SkScan::SAAFillPath и MaskSuperBlitter это записывает данные за границами фиксированного буфера стека. MaskSuperBlitter обрабатывает только крошечные path размером до 32 на 32 пикселя и хранит 8-битные значения покрытия в массиве фиксированного размера.

Результат — полезный примитив повреждения стека в Chrome. Это не простое линейное переполнение: наклоны рёбер 7 и 8 управляют затронутыми смещениями.

Чтобы нужная фигура казалась выпуклой и при этом помещалась в 32 на 32 пикселя, нужно начать с монотонного по x path, почти сплющить его вдоль оси x и повернуть, пока проверка выпуклости не посчитает его также монотонным по y. Итоговое преобразование canvas обращает эти операции и восстанавливает опасную геометрию.

Об исправлении проблемы

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

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

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

Заключение

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

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

Наконец, эшелонированная защита важна. Исправление одного искажённого RRect оставляет неизвестные способы неверно классифицировать выпуклость. Безопасное завершение работы растеризатора только для выпуклых фигур при нарушении его предусловия защищает и от известных, и от будущих вариантов.

• Messages, стандартное приложение SMS Android;

• Gmail для Android;

• Microsoft Outlook;

• Facebook Messenger;

• WhatsApp;

• Signal;

• Telegram.

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

Когда путь содержал символическую ссылку Object Manager, созданную в песочнице, IoCreateFile возвращала STATUS_OBJECT_NAME_NOT_FOUND. ObpParseSymbolicLink реализует защиту символических ссылок, добавленную в Windows 10. У созданной в песочнице ссылки есть SANDBOX_FLAG; при её разборе вызывается RtlIsSandboxedToken, проверяющая, остаётся ли текущий вызывающий процесс в песочнице.

Вызывающей стороной действительно был процесс в песочнице, однако RtlIsSandboxedToken возвращала false. Причиной стал аргумент AccessMode: он был равен KernelMode. Функция считает KernelMode доверенным и сразу сообщает, что вызывающий процесс не находится в песочнице.

Предыдущий режим доступа

Каждый поток Windows хранит предыдущий режим процессора в KTHREAD.PreviousMode, доступный сторонним драйверам через ExGetPreviousMode(). Переход системного вызова из пространства пользователя устанавливает его в UserMode, хотя выполнение уже происходит внутри кода ядра.

KernelMode используется для системных потоков или имитации перехода системного вызова, инициированного из кода ядра. Например, пользователь может вызвать драйвер через NtFsControlFile; драйвер всё равно выполняется с предыдущим режимом UserMode. Но если драйвер вызывает ZwOpenFile, ядро имитирует переход и выполняет NtOpenFile с предыдущим режимом KernelMode.

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

• Проверка прав доступа (SecAC): такие функции, как SeAccessCheck() и SePrivilegeCheck(), определяют, может ли вызывающая сторона обращаться к объекту. Передача KernelMode обычно обходит эти проверки.

• Проверка доступа к памяти (MemAC): точки входа ядра проверяют, что предоставленные пользователем указатели находятся ниже MmUserProbeAddress, часто через ProbeForRead() или ProbeForWrite(). Передача KernelMode разрешает указатели ядра и отключает probing.

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

Проверка доступа в IO Manager

IO Manager предоставляет две группы файловых API. NtCreateFile/ZwCreateFile и NtOpenFile/ZwOpenFile являются точками входа системных вызовов. IoCreateFile и IoCreateFileEx — интерфейсы только для ядра. В конце концов они передают управление IopCreateFile, которая обычно использует предыдущий режим потока и для SecAC, и для MemAC.

Вызов NtCreateFile из пространства пользователя выполняет обе проверки. Вызов ZwCreateFile из режима ядра временно устанавливает предыдущий режим в KernelMode, отключая обе. IoCreateFile не выполняет переход, поэтому драйвер, вызванный из пространства пользователя, сохраняет UserMode. Это сохраняет SecAC, но также заставляет IopCreateFile проверять указатели ядра драйвера.

Проблему решает аргумент Options:

• IO_NO_PARAMETER_CHECKING (INPC) сообщает IO Manager не проверять параметры, разрешая адреса ядра. Он также отключает некоторые проверки несовместимых флагов.

• IO_FORCE_ACCESS_CHECK (IFAC) запрашивает проверки безопасности даже для доверенной вызывающей стороны ядра.

• Отдельно поддерживаемый IO_CHECK_CREATE_PARAMETERS восстанавливает проверку флагов, не включая MemAC.

Ключевое упрощение реализации: INPC устанавливает передаваемый дальше AccessMode в KernelMode:

Таким образом, INPC отключает и MemAC, и SecAC на границе Object Manager. Он не меняет KTHREAD.PreviousMode — изменяется лишь передаваемый аргумент. IFAC отдельно переносится в контексте разбора для последующей обработки IO.

OBJ_FORCE_ACCESS_CHECK (OFAC) в OBJECT_ATTRIBUTES предоставляет другой путь. ObpLookupObjectName() видит флаг и принудительно возвращает локальный режим доступа в UserMode, даже при вызове через ZwCreateFile или запросе INPC.

Это объясняет исходное поведение шрифтов. Разбор символической ссылки происходит в Object Manager, который не знает об IFAC. IopCreateFile передала KernelMode из-за INPC, поэтому RtlIsSandboxedToken сочла вызывающую сторону доверенной. Итоговое открытие файла всё равно выполняло SecAC, поскольку IO Manager понимал IFAC. Добавление OFAC заставило бы разбор в Object Manager также использовать UserMode.

Поэтому любой parse callback Object Manager, доверяющий аргументу режима доступа, может обходить проверки безопасности без OFAC. Однако центральный класс ошибок находится уровнем глубже.

Разбор устройств IO

Object Manager прекращает обычный разбор пути, достигнув именованного объекта устройства. Он вызывает процедуру разбора типа Device — IopParseDevice, передавая остаток пути, контекст разбора и режим доступа. Функция проверяет устройство, выделяет IO Request Packet (IRP) и отправляет его драйверу устройства.

IRP.RequestorMode.aspx) сохраняет режим доступа запроса, поскольку IO может быть асинхронным и выполняться в другом потоке. Можно ожидать, что IFAC установит поле в UserMode. Но этого не происходит: вызов IoCreateFile с INPC всё равно создаёт RequestorMode == KernelMode.

Операция и её параметры находятся в соседней IO_STACK_LOCATION. Для IRP_MJ_CREATE IFAC превращается во флаг stack location SL_FORCE_ACCESS_CHECK (SFAC). Принимающий драйвер файловой системы должен объединять RequestorMode с этим флагом, а не доверять одному RequestorMode.

NTFS делает это через helper эффективного режима:

NTFS тесно связан с IO Manager, поэтому такое поведение неудивительно. Но Windows рассматривает любой драйвер устройства как своего рода цель файловой системы, даже если он не реализует обычную файловую систему. Многие ли драйверы знают, что нужно проверять SFAC?

Определение класса ошибок

Для повышения привилегий нужны два компонента:

1. Инициатор режима ядра вызывает IoCreateFile или IoCreateFileEx с INPC и IFAC, но без OFAC.

2. Уязвимый получатель обрабатывает IRP_MJ_CREATE, принимает решение безопасности на основе RequestorMode и не учитывает SFAC.

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

Вызовы без IFAC могут быть ещё хуже: SFAC не создаётся, поэтому даже NTFS может пропустить проверки безопасности. Связанные API вроде FltCreateFileEx ведут себя аналогично. Недокументированные детали делают IoCreateFileEx особенно неожиданной: она всегда передаёт INPC в IopCreateFile, поэтому без OFAC её операции используют KernelMode.

Идеальный инициатор принимает произвольный пользовательский путь и параметры создания, затем возвращает открытый дескриптор. Получатель может разобрать оставшееся имя файла и открыть другой ресурс, интерпретировать блок Extended Attributes (EA) или просто пропустить проверку доступа к объекту устройства.

Примеры

Приведённые ниже примеры взяты из Windows 10 1709. Многие сохранились в новых сборках Windows 10 и Windows 7 или 8. Они были найдены ручным анализом бинарных файлов, без специализированных инструментов статического анализа.

Получатели

Получателей искать сложнее, поскольку единого импорта, идентифицирующего их, нет. Я искал драйверы, импортирующие IoCreateDevice, а затем отдавал приоритет тем, которые также импортировали API с явным AccessMode, например SeAccessCheck или ObReferenceObjectByHandle. Обычные файловые системы, включая NTFS и FAT, похоже, правильно обрабатывали SFAC.

Одним из получателей был WS2IFSL. Когда он включён, он создаёт файловые объекты, передающие чтение и запись пользовательскому приложению через APC. EA выбирает socket file или process file, а CreateProcessFile строит APC по данным EA. Драйвер доверял RequestorMode; несогласованный запрос мог пометить callback как KernelMode. Предоставленный дескриптор потока также связывался с этим режимом, потенциально допуская дескрипторы ядра, хотя поток всё равно должен был принадлежать вызывающему процессу.

Для эксплуатации нужен инициатор, способный предоставлять EA, создание socket file со ссылкой на process file и операция IO для доставки APC. Современная Windows также имеет SMEP и Kernel CFG: направление callback в пространство пользователя вызывает bugcheck при попытке выполнения в режиме ядра.

NPFS правильно проверяет SFAC для обычного контроля доступа, но всё же использует RequestorMode, чтобы решить, разрешены ли произвольные EA. Именованные каналы обычно записывают PID и session ID вызывающей стороны, доступные через API вроде GetNamedPipeClientProcessId. Пользовательские вызывающие стороны не могут задавать эти поля, а стороны режима ядра могут, что поддерживает перенаправление SMB. Поэтому несогласованный запрос способен подделать PID и session ID.

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

Инициаторы

Инициаторы искать проще: достаточно найти в ядре и драйверах вызовы IoCreateFile и связанных API, а затем исследовать options, object attributes и контролируемые пользователем аргументы.

При переименовании файла IopOpenLinkOrRenameTarget открывает выбранный атакующим целевой путь через IoCreateFileEx, передавая INPC и обычно IFAC. Путь контролируется, хотя цель переименования должна оставаться на исходном томе.

Серверы SMB также вызывают IoCreateFileEx, например в Smb2CreateFile. Они работают в системных потоках, поэтому предыдущий режим уже равен KernelMode, и используют IFAC. Обычно клиент предоставляет путь относительно уже открытого тома; точки подключения не могут перенаправить его к произвольным классам устройств, поскольку ядро проверяет целевое устройство.

Ошибка реализации обходила ограничение. SMBv2 должен возвращать клиенту информацию о символических ссылках NTFS. Поэтому он передаёт IO_STOP_ON_SYMLINK. Когда открытие возвращает STATUS_STOPPED_ON_SYMLINK, сервер получает REPARSE_DATA_BUFFER и передаёт его в SrvGraftName.

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

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

Но и он не был идеален. Для возврата пригодного дескриптора получатель должен был реализовывать такие запросы, как IRP_MJ_QUERY_INFORMATION; SMB также ограничивает управляющие коды IO. Эти ограничения помешали очевидной цепочке APC через WS2IFSL. Тем не менее Microsoft сочла перенаправление серьёзным и исправила проблему Project Zero 1416 / CVE-2018-0749, используя Extra Creation Parameter, разрешающий только предполагаемое поведение reparse символических ссылок.

Следующие шаги

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

Вместо того чтобы отложить поведение на будущее, я обратился в MSRC и описал класс и примеры. Проблема SMB прошла обычный процесс сообщения об уязвимости. На встречах BlueHat 2017 появился план: Microsoft с доступом к исходному коду систематически исследует код ядра и драйверов Windows. Исходников Windows у меня не было; эту часть расследования выполнила MSRC.

Для отчёта SMB сохранился стандартный 90-дневный срок Project Zero. Для общего отчёта о классе ошибок его не было, поскольку единственного дефекта для исправления не существовало, а срок было бы трудно применить продуктивно. MSRC всё же согласилась опубликовать технические подробности независимо от результата, что примерно через двенадцать месяцев привело к согласованным публикациям.

Выводы

К счастью, на практике этот класс оказался менее опасен, чем мог бы быть. Более чистая архитектура использовала бы отдельные режимы для MemAC и SecAC, но исходный контракт NT применяет один и не может реалистично измениться без проблем совместимости.

Плохая документация была не менее важна, чем реализация. Microsoft добавила рекомендацию: запрос создания, исходящий от пользователя и использующий одновременно IO_NO_PARAMETER_CHECKING и IO_FORCE_ACCESS_CHECK, должен также устанавливать OBJ_FORCE_ACCESS_CHECK в OBJECT_ATTRIBUTES.

Разработчикам следует изучить рекомендации Microsoft по предотвращению этого класса и аудиту существующих драйверов. Исследователи безопасности должны с подозрением относиться к RequestorMode == KernelMode, если IRP мог возникнуть из контролируемой пользователем операции, и всегда проверять SL_FORCE_ACCESS_CHECK и полный путь создания.

Спасибо Стивену Хантеру и Гэвину Томасу из MSRC за руководство устранением этого класса ошибок.

Современная отладка Windows использует объект ядра Debug, создаваемый через NtCreateDebugObject. Он связывает целевые процессы и ставит их события отладки в очередь. Win32 скрывает создание объекта и хранит debug object каждого потока в его TEB.

Документированный интерфейс DebugActiveProcess принимает PID:

В конце концов он вызывает нативный API, принимающий дескрипторы:

Объект Debug берётся из TEB. Win32 должен преобразовать PID в дескриптор процесса. Его helper запрашивает все права, обычно нужные отладчику:

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

Ядро преобразует дескриптор обратно в EPROCESS с помощью ObReferenceObjectByHandle, но запрашивает лишь одно право доступа:

Уровень Win32 требует гораздо больше доступа, чем нативная операция. С точки зрения ядра подключение немедленно приостанавливает процесс, а последующий NtDebugContinue возобновляет его. Ядру безразлично, может ли отладчик использовать адреса, сообщённые в событиях. Это похоже на другие несоответствия интерфейсов, например поведение жёстких ссылок, рассмотренное в Between a Rock and a Hard Link.

Вопрос в том, что атакующий может сделать, имея только PROCESS_SUSPEND_RESUME.

Доступ к событиям отладки

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

Событие создания содержит hFile, hProcess и hThread. Объекты ядра захватываются при подключении, но дескрипторы создаются позднее функцией NtWaitForDebugEvent внутри DbgkpOpenHandles:

ObOpenObjectByPointer вызывается с KernelMode, обходя проверки доступа, и запрашивает все права процесса и потока. Следовательно, дескриптор PROCESS_SUSPEND_RESUME можно через API отладчика повысить до полноправных дескрипторов процесса и начального потока.

Приём эксплуатации 1: преобразовать дескриптор процесса только с PROCESS_SUSPEND_RESUME в полноправный дескриптор процесса через нативные API отладчика.

NtObjectManager делает PoC лаконичным:

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

Кража дескриптора исполняемого файла

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

Изначально дескриптор создаётся при подключении:

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

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

Проблема Project Zero 274 в драйвере Novell демонстрирует примитив. При записи журнала драйвер не проверял успешность ZwOpenFile. При ошибке он передавал устаревшее значение стека в ZwClose, создавая произвольное закрытие дескриптора ядра.

Эксплойт может:

1. Создать запись журнала, чтобы дескриптор ядра был выделен, закрыт, а его значение осталось на стеке.

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

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

4. Вызвать код ядра, который повторно выделит то же значение дескриптора для более интересного объекта. SepSetTokenCachedHandles, доступная через NtCreateLowBoxToken, может дублировать выбранные дескрипторы ядра, хотя проверки, добавленные после проблемы 483, ограничивают кандидатов.

5. Получить событие отладки и через устаревшее значение дескриптора получить недавно выделенный объект.

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

Итоги

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

• Подключение отладчика повышает PROCESS_SUSPEND_RESUME до полных дескрипторов процесса и потока.

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

Несоответствия между слоями интерфейса заслуживают внимания, даже когда каждый слой ведёт себя согласованно со своими предположениями. Модель ядра «раз вы подключили отладчик, вам, конечно, нужны эти дескрипторы» не эквивалентна контракту доступа, обеспечиваемому Win32.

Ошибка находилась в JSCallReducer::ReduceArrayIndexOfIncludes — проходе оптимизации, заменяющем Array.prototype.indexOf или includes специализированным кодом, когда TurboFan знает вид элементов массива. Виды элементов V8 описывают, хранит ли массив значения с плавающей точкой, помеченные указатели, упакованные значения, пропуски или словарь.

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

Но InferReceiverMaps имеет три возможных результата:

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

Код, зависящий от конкретной карты, должен вставить узел CheckMaps или зарегистрировать зависимость компиляции. StableMapDependency позволяет обойтись без встроенной проверки, деоптимизируя скомпилированный код, если предположительно стабильная карта позднее изменится. Оба подхода требуют осторожности: вызывающая сторона может забыть о зависимости, а путь перехода — не сделать её недействительной.

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

Минимизированный пример Самуэля:

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

Array.prototype.indexOf использует строгое равенство. Для объектов кучи это обычно равенство указателей, а примитивные значения сравниваются по значению. Поскольку единственный наблюдаемый результат — индекс элемента, очевидный примитив утечки заключается в полном переборе указателя, пока indexOf не сообщит его положение за пределами памяти.

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

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

Первые попытки завершались сбоем примерно после 0x2000000 сравнений. Сборка мусора перемещала объекты и разрушала подготовленное расположение. Решение простое: после 0x1000000 неудачных предположений выделить новый ArrayBuffer и начать заново, пока его адрес не попадёт в исследуемый диапазон.

Произвольная запись

У строгого равенства есть важный особый случай для строк. V8 поддерживает SeqString, SlicedString, ConsString и другие представления. Если две строки имеют одинаковую длину и первый символ, перед побайтовым сравнением они могут быть сведены к последовательным строкам.

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

Один из возможных путей — повреждённая ConsString, сумма длин левой и правой частей которой превышает общую длину, что переполняет буфер назначения, выделенный для сведения. Это работало, но последующие записи попадали в области около смещений INT_MIN или INT_MAX и вызывали сбой.

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

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

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

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

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

Выделения нового пространства линейны, поэтому массив-жертва находится по предсказуемому смещению от раскрытой сведённой строки. Затем примитив установки бита увеличивает его длину. После этого стандартные методы эксплуатации V8 превращают массив с доступом за границы в раскрытие адресов объектов и произвольную запись. В описании эксплуатации V8 Андреа Бьондо рассмотрены эти последующие примитивы. Эксплойт через повреждение длины массива приложен к проблеме Project Zero 1809 и нацелен на вручную собранный Chrome 74.0.3728.0.

Заключение

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

V8 быстро исправила непосредственную ошибку и запланировала переработать InferReceiverMaps, чтобы вызывающие стороны не могли незаметно считать ненадёжные карты надёжными. Ранее я проверял места её вызова, поскольку API выглядел простым для неправильного использования, но тогда не нашёл проблем; позже добавленный код совершил именно эту ошибку.

О подозрительных API стоит сообщать и улучшать их ещё до возникновения уязвимости. Внешние участники могут предлагать профилактические переработки через программу вознаграждений V8 Patch Reward Program. Устранение шаблона ошибок зачастую ценнее исправления одного экземпляра после эксплуатации.

CommCenter также содержит запускаемый через XPC симулятор SMS, который обрабатывает PDU доставки так, словно они пришли по сети. Для работы симулятора пришлось повторно реализовать отсутствующую библиотеку внутренних тестовых устройств. Фаззинг через него не нашёл ошибок SMS, но инструмент оказался полезен для многократного вызова поведения Visual Voicemail.

MMS

CommCenter обрабатывает MMS преимущественно через MmsOperation::decodeMessage. Ни анализ в IDA, ни запускаемый на устройстве harness, вызывающий этот метод, не обнаружили уязвимости.

Visual Voicemail

processReceivedSms_sync распознаёт и пересылает особым образом отформатированные payload SMS. Visual Voicemail получает сообщения с IMAP-сервера оператора; оператор отправляет его URL и учётные данные по SMS. Формат Apple отличается от публичной OMTP_VVM_Specification_v1_3_Final.pdf (файл в files/OMTP_VVM_Specification_v1_3_Final.pdf). Перехваченная конфигурация выглядит примерно так:

Тестирование сырых PDU показало, что атакующий может перенаправить цель на произвольный IMAP-сервер при следующих условиях:

• Visual Voicemail уже настроена с приветствием.

• PID SMS соответствует значению VVM оператора.

• Оператор не блокирует IMAP-соединения с внешними серверами.

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

VVM повторно использует IMAP-клиент iOS Mail. IMAP-серверы обычно укрепляют против вредоносных клиентов; клиенты реже тестируют против вредоносных серверов, поскольку пользователи обычно вручную настраивают доверенных провайдеров. Управляемое оператором SMS незаметно меняет эту модель доверия.

Поддельный сервер возвращал искажённые ответы, пока симулятор SMS многократно вызывал соединения. Так была найдена CVE-2019-8613 — use-after-free объекта NSString при обработке NAMESPACE. Клиент получает разделитель mailbox через LIST. Обработка ошибки освобождает разделитель, но вызывающая сторона продолжает выполнение NAMESPACE без проверки успеха и использует устаревшую строку.

Электронная почта

Пути MIME, не используемые VVM, раскрыли ещё одну проблему. MFMimePart _contents:toOffset:resultOffset:downloadIfNecessary:asHTML:isComplete: выбирал decoder, добавляя недоверенный тип MIME к decode и вызывая полученный selector. Поэтому специально подготовленный тип мог вызвать непредусмотренный метод и повредить память.

Проблема была найдена в iOS 11.3.1. Несвязанные изменения selector сделали эксплуатацию непрактичной в iOS 12, хотя crash сохранился; Apple исправила её как CVE-2019-8626.

Практическая доступность электронной почты зависит от использования нативного клиента Apple и фильтрации провайдера. Payload работал через Gmail, настроенный в Mail, но другие провайдеры могут удалять искажённые компоненты MIME.

iMessage

iMessage поддерживает расширенные сообщения и расширения Apple или сторонних разработчиков. Для macOS были написаны инструменты на Frida, выгружающие и заменяющие исходящие и входящие сообщения. Базовое сообщение представляет собой бинарный plist:

Некоторые поля содержат данные NSKeyedArchiver, при необходимости сжатые gzip. SpringBoard десериализует bp без взаимодействия для создания уведомлений и не находился в песочнице. MobileSMS также декодирует его после одного нажатия. imagent автоматически декодирует более ограниченное поле ati.

Secure coding не является полным allowlist

Архив представляет графы объектов Objective-C как словари plist и числовые ссылки. Например, сериализованный NSURL называет класс и ссылается на объекты для NS.base и NS.relative.

NSSecureCoding требует, чтобы классы явно включали поддержку через requiresSecureCoding, а вызовы декодирования указывали разрешённые классы. Это ограничивает возвращаемый тип, но не каждый конструктор, доступный внутри. Сам NSURL initWithCoder: декодирует значения NSData и NSString:

API initForReadingFromData: и unarchivedObjectOfClasses:fromData:error: по умолчанию включают secure coding. Похоже названные initWithData:, unarchiveObjectWithData:error: и initForReadingWithData: не включают. iMessage не предоставлял небезопасного пути, пригодного для свободной десериализации объектов WebKit.

Расширения

SpringBoard может вызывать методы предварительного просмотра расширения без взаимодействия. Некоторые проверенные версии также автоматически вызывали initWithPluginPayload:; поведение различалось между выпусками.

CVE-2019-8624 затрагивала Digital Touch, который использует protobuf вместо keyed archive. Неверная проверка длины массива байтов приводила к чтению за границами. Вероятно, проблема была неэксплуатируемой, но демонстрировала полностью удалённый путь расширения.

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

Разрешённые подклассы

При декодировании SpringBoard разрешал NSDictionary, NSString, NSData, NSNumber, NSURL, NSUUID и NSValue для bp. Принимался любой подкласс на любой глубине наследования, включая скрытые классы, косвенно импортированные SpringBoard.

Анализ их реализаций initWithCoder: дал следующие результаты:

• CVE-2019-8663: SGBigUTF8String, подкласс NSString, считает декодированные байты завершающейся нулём строкой UTF-8 даже при отсутствии терминатора, создавая строку из памяти за границами.

• CVE-2019-8661: декодирование bookmark NSURL в macOS принимает устаревшие данные alias alis. CarbonCore обрабатывает их небезопасными строковыми операциями, а strcat повреждает кучу. iMessage никогда легитимно не использует эту функцию; универсальная десериализация NSURL внесла её в поверхность атаки.

• CVE-2019-8646: скрытый подкласс NSData _NSDataFileBackedFuture независимо декодирует имя файла и длину буфера, не проверяя настоящий размер файла, нарушает инвариант длины/байтов NSData и позволяет повредить память.

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

• CVE-2019-8647: _PFArray наследует декодирование NSArray и переопределяет initWithObjects:count: с предположением, что каждый элемент имеет удерживаемую ссылку. При десериализации предположение нарушается, создавая массивы уже освобождённых объектов.

• CVE-2019-8662: связанная уязвимость в классе, который, насколько известно, не импортировался iMessage, но, вероятно, доступен в других десериализующих приложениях.

Циклические графы объектов

Числовые ссылки объектов допускают самоссылки и циклы. Decoder приблизительно выделяет объект, помещает неудерживаемый указатель во временную map, вызывает initWithCoder:, а затем заменяет временную запись возвращённым объектом в удерживающей map:

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

• CVE-2019-8641 эксплуатировала цикл; раскрытие сначала отложили, поскольку первое исправление было неполным. Она анализируется в Remote iPhone Exploitation Part 1.

• CVE-2019-8660 затрагивала NSKnownKeysDictionary1. Её NSKnownKeysMappingStrategy1 отдельно декодирует количество ключей и проверяет его лишь после декодирования массива ключей. Циклический ключ использует strategy до проверки, делая доступным повреждение из-за целочисленного переполнения.

Экспоненциальный рост поверхности атаки

Даже этот на вид узкий вызов имеет широкую область действия:

Он включает подклассы NSURL из каждого загруженного framework. NSURL initWithCoder: добавляет NSString, NSData и парсеры bookmark. Их подклассы добавляют новые decoder. В приложении, импортирующем UserNotifications, примерами служат _NSDispatchData, __NSLocalizedString, NSLocalizableString и UNLocalizedString. Те в свою очередь декодируют массивы, словари, числа и даты, рекурсивно допуская их подклассы.

Наследование расширяет поверхность за пределы initWithCoder:: decoder суперкласса вызывают переопределённые методы подкласса вроде initWithString: и initWithBytes:length:encoding:. Классы из несвязанных framework также можно объединять в графы объектов, которых их авторы никогда не ожидали. Поэтому эффективный allowlist расширяется с каждой импортированной библиотекой и каждым дополнительным корневым классом.

Заключение

Исследование охватило SMS, MMS, Visual Voicemail, электронную почту и iMessage и привело к сообщениям о десяти исправленных уязвимостях. VVM неожиданно превратила почтовый клиент в удалённый парсер вредоносного сервера. Большинство находок дала iMessage, поскольку keyed-десериализация объединила подклассы, вложенные decoder, наследование, скрытые типы framework и циклические графы в поверхность атаки, гораздо более крупную, чем требовало обычное поведение продукта.

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