Во время хакатона Project Zero по Samsung в конце 2019 года старые отчёты о libSecMMCodec.so, libQjpeg.so и libfacerecognition.so подсказали, что стоит исследовать машинную обработку изображений.

Именно этих библиотек на Galaxy A50 не было, но символы Quram обнаружились в:

Файл Samsung /system/etc/public.libraries-quram.txt перечисляет библиотеки поставщика в каждой сборке. Quramsoft много лет снабжала Samsung кодеками изображений, аудио, видео и анимации; их названия и упаковка неоднократно менялись.

libimagecodec.quram.so была большой и доступной из Галереи, но её доступность из MediaScanner не была очевидна. Сканер AOSP сводил исследование изображения к BitmapFactory.decodeFile:

Обнаружение Skia и Qmage

Путь Java достигает машинной Skia через decodeStreamInternal, nativeDecodeStream и doDecode. Skia создаёт кодек и запрашивает у него пиксели:

В зависимости от флагов сборки вышестоящая Skia распознаёт PNG, JPEG, WebP, GIF, ICO, BMP, WBMP, HEIF и raw/DNG. В /system/lib64/libhwui.so от Samsung добавлены проверки сигнатур:

Среди других дополнений Samsung — альтернативная сигнатура PNG \x89PIO. Qmage был привлекательной целью: сотни длинных низкоуровневых функций Quram, глубокая интеграция с системой и почти полное отсутствие открытой документации.

Подробнее о кодеке Версии формата

Проверка версии QG принимает старшие версии меньше 2 и ровно 2.0:

Фактически наблюдались форматы QG 1.0, 1.1 и 2.0. Более старая проверка QM допускает QM версии 1 и содержит оставшиеся распознаватели IM, IT, IFEG, QW и PFR — вероятно, родственных или устаревших форматов Quram.

Таким образом, поддерживаются четыре поколения статических изображений: QMv1, QG1.0, QG1.1 и QG2.0. Символы старых ответвлений имеют суффиксы ревизии и даты; имена без суффиксов представляют QG2.0.

Неиспользуемая функция версии печатает X.Y.Z.R и время сборки. X.Y отражает новейший формат QG, а R — ревизию кода.

Разработка была наиболее активной с 2014 по 2016 год; QG2.0 вошёл в производственные сборки в сентябре 2019 года. Шесть временных меток трёх поколений QG и двух архитектур показывают, что одна сборка занимала как минимум 2 минуты 36 секунд:

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

Область Qmage за сентябрь 2019 года занимает около 908 КБ — примерно 15% исполняемого кода libhwui.so. Копия из Android 9 уже занимала около 425 КБ. Восемнадцать из двадцати самых длинных функций библиотеки относились к Qmage.

Декодирование заголовка проходит так:

Даже inJustDecodeBounds достигает построения таблицы цветов, где было обнаружено повреждение памяти. Полное декодирование пикселей продолжается через SkQmgCodec::onGetPixels, QuramQmageDecodeFrame, _QM_WCodec_decode и выбранный низкоуровневый декодер.

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

Поиск входных образцов

По-видимому, Qmage предназначен для статических ресурсов в APK и темах Samsung, а не для создаваемых пользователями медиафайлов. Ресурсы прошивок непредсказуемо смешивают Qmage, ASTC, PNG/PIO, BMP, JPEG, SVG, WebP, SPR и двоичный XML в разных устройствах и выпусках.

Полезные корпуса QMv1, QG1.0 и QG1.1 нашлись главным образом в прошивках Galaxy Note 3/4/5 от Android 4.4.4 до 6.0.1. Ни одного настоящего образца QG2.0 обнаружить не удалось; позднее фаззинг синтезировал их из входных данных QG1.x.

Извлечение SecSettings.apk из системного образа Note 4 открывает каталоги drawable:

accessibility_light_easy_off.qmg начинается с заголовка QG1.1:

После переименования файла в .png или .jpg обычные приложения Samsung распознают его.

Следы открытого исходного кода

Когда-то Samsung публиковала свои изменения Skia в крупных архивах исходников Lollipop. SkImageDecoder_libqmage.cpp оборачивает QuramQmageDecParseHeader и QuramQmageDecodeFrame; он не раскрывает проприетарную реализацию, но подтверждает детали интеграции.

Анимации загрузки, старые парсеры и символы

Qmage появился раньше интеграции со Skia в 2014 году. Samsung до сих пор хранит анимации загрузки и завершения работы в /system/media/*.qmg, используя версии анимации QM от 0x0b до 0x0f. bootanimation декодирует их отдельной libQmageDecoder.so.

Старые копии этой библиотеки из Android 2.1–4.3 сохранили богатые отладочные метаданные: пути и номера строк исходников, структуры, перечисления и локальные переменные. Сборка 2013 года определяет QmageDecCommon.c, QmageDecoder.c и крупные файлы декодеров V/F/W общим объёмом в тысячи строк.

Прошивки Samsung до Android также содержат Qmage и IFEG.

Прошивка GT-B5722 2009 года использует и .qmg, и .ifg; общие предки декодеров указывают, что IFEG, вероятно, был предшественником. Прошивка SGH-D600 2005 года уже содержит IFEG, что соответствует заявленному Quramsoft началу сотрудничества с Samsung. В то время поставщик назывался I-master, чем объясняются старые сигнатуры и символы IM.

Первые эксперименты с кодеком

Изменение размеров допустимого образца с 344 на 345 заставляет Галерею корректно отклонить его:

Изменение обоих размеров на 1368 немедленно вызывает сбой Галереи.

Ошибка происходит в PVcodecDecoder_GrayScale_16bits_NEW, достигнутой через _QM_WCodec_decode, Qmage_WDecodeFrame_Low и SkQmgCodec::onGetPixels.

Отправка того же некорректного файла через MMS воспроизводит сбой в com.samsung.android.messaging в фоновом потоке пула без открытия сообщения. Samsung Messages автоматически декодирует входящие изображения до взаимодействия пользователя, делая хрупкий кодек удалённо доступным по одному номеру телефона.

Этот результат послужил причиной фаззинга с обратной связью по покрытию и задачи Project Zero 2002. В части 2 разрабатывается стратегия фаззинга.

Заключение

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

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

Фаззинг на физических устройствах плохо масштабируется. Копирование /system/lib64, linker64, библиотек среды выполнения Android и зависимостей NDK на хост x86-64 позволяет qemu-aarch64 выполнять тот же бинарный файл:

Среда выполнения UBSan из Android 10 завершалась аварийно, поскольку в QEMU отсутствовал специфичный для санитайзера prctl; замена средой Android 9 восстановила работу. Один образец занимал 120 мс на устройстве и 380 мс в эмуляции — приемлемое исходное замедление в три раза.

Собственные отчёты о сбоях в стиле ASAN

Обычно эмулируемая ошибка выглядит лишь как SIGSEGV внутри сгенерированного QEMU кода x86. Машинные кадры стека определяют code_gen_buffer и cpu_exec, а не инструкцию ARM или функцию libhwui, делая автоматическую сортировку невозможной.

Тестовая среда устанавливает обработчик сигналов, выводящий совместимый с AddressSanitizer префикс и подробности эмуляции:

Стек в стиле ASAN интегрируется с существующей дедупликацией. Дизассемблирование Capstone и регистры помогают ручной сортировке. Символы предоставляет libbacktrace.

Потребовалось обработать несколько пограничных случаев:

• Для доступного только на выполнение кода Android 10 перед дизассемблированием требовался mprotect.

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

• abort() маскирует сигналы кроме SIGABRT, что требует исправления через sigprocmask.

• Смещения ошибок внутри memcpy, memmove и memset нормализовались до начала функции, чтобы исключить ложную уникальность.

Аллокатор для фаззинга на основе libdislocator

jemalloc в Android скрывает небольшие обращения за границами и создаёт недетерминированные вторичные сбои. Маленькая libdislocator из AFL реализует выделения с помощью mmap/mprotect, помещает каждый объект на границу страницы, заполняет новую память значением 0xcc и перехватывает нарушения в месте их возникновения.

Её скомпоновали с тестовой средой и выбрали через механизм malloc_hook Android с LIBC_HOOKS_ENABLE=1. Те же хуки реализуют --log_malloc, позднее пригодившийся для понимания расположения кучи эксплойта.

Отличия от jemalloc имеют значение:

• Ограничение в 1 ГБ раскрывает ошибки давления на память, но может скрывать пути, которым нужны более крупные успешные выделения.

• QEMU не применяет все ограничения выравнивания ARM, а libdislocator может возвращать невыровненные блоки; переполнения на 1–7 байт способны попадать в заполнение.

• Запуски на физическом Android по-прежнему выравнивают блоки, чтобы исключить ложные ошибки SIGBUS.

• Инициализация 0xcc делает использование неинициализированной памяти детерминированным, тогда как содержимое настоящего jemalloc требует подготовки кучи.

Реализация fork-сервера QEMU

Запуск загрузчика без входных данных всё равно занимал 360 мс — около 95% полного 380-мс декодирования. Большая часть времени уходила на запуск эмулируемого компоновщика и процесса, а не на разбор изображения.

Подход QEMU из AFL адаптировали для QEMU 4.1.1:

1. load_elf_image записывает точку входа ELF загрузчика.

2. cpu_tb_exec обнаруживает первый транслированный блок по этому адресу и вызывает forkserver_main внутри эмулируемой среды.

На рабочих серверах фаззинга декодирование корпуса ускорилось с 1160 до 56 мс — в 20,5 раза. С покрытием и -d nochain время сократилось с 6900 до 147 мс — примерно в 47 раз. Устранение фиксированной стоимости запуска было критически важно для масштабирования.

QemuSanitizerCoverage

Фаззер потреблял файлы .sancov, поэтому QEMU расширили для вывода адресов базовых блоков в формате, совместимом с SanitizerCoverage. Журналирование -d exec в QEMU уже получает каждый транслированный блок в cpu_tb_exec; callback-функция записывает itb->pc в битовую карту соответствующего отображённого исполняемого файла. Неизвестные адреса запускают разбор /proc/pid/maps. Файлы покрытия записываются при завершении.

Файл содержит восьмибайтный заголовок 32-разрядного формата, за которым следуют смещения базовых блоков относительно отображения текста каждой библиотеки. Его можно преобразовать для визуализации в Lighthouse и использовать при минимизации корпуса.

Исходный корпус

APK из прошивок предоставили начальные файлы QMv1, QG1.0 и QG1.1. Управление по покрытию быстро заменило большинство оригиналов мутированными файлами размером 20–50 байт, предпочитая более короткие входные данные с теми же блоками.

Настоящих файлов QG2.0 не нашлось. Жёсткая установка 2.0 в старых заголовках сначала вызывала главным образом поверхностные сбои и давала лишь несколько жизнеспособных начальных файлов, но за несколько дней фаззинга покрытие QG2.0 приблизилось к старым форматам. Сеансы Android 9 покрыли 18 268 блоков Qmage; сеансы Android 10 со всеми версиями достигли 29 081 — рост на 59%, соответствующий увеличению кода с 425 до 908 КБ.

QG2.0 проверяет однобайтовую контрольную сумму длины файла:

Фаззер обнаружил 257-байтные файлы, контрольная сумма которых естественным образом равна нулю. Он также синтезировал множество несуществующих файлов QG1.2. Разрешающая проверка версии принимала их, а ошибка реализации сопоставляла версию X.Y внутренней версии Y, если это не ровно 2.0. Поэтому QG1.2 выбирала пути QG2.0 без контрольной суммы — изящный обход, найденный мутациями.

Настройки мутаций

Кампания использовала простые мутации: инверсию битов, замену случайных байтов, специальные целые числа, арифметические изменения и вырезание/вставку непрерывных фрагментов. Применялись пары мутаций, иногда запускалась Radamsa, а доля мутаций составляла от 0 до 0,1%.

Результаты Покрытие кода

Если считать только функции, достигнутые хотя бы один раз, было покрыто 87,30% базовых блоков Qmage. В 34 функциях размером более 4 КБ находилось 26 670 блоков, из которых достигнуто 23 069, или 86,50%. Покрытие каждого тяжёлого декодера превысило 60%, большинства — 80%.

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

Сбои

Четыре недели фаззинга Android 9 и Android 10 в декабре 2019 и январе 2020 года дали 5218 уникальных сигнатур по трём кадрам стека.

Записи по ненулевым адресам напрямую свидетельствуют о повреждении. Крупные чтения и ошибки универсальных операций с памятью могут раскрывать недопустимые структуры или указатели. Большинство чтений от одного до четырёх байт — простые чтения за пределами входных данных; abort и ошибки вблизи null обычно менее опасны.

Исходная автоматизация ошибочно помечала некоторые неканонические произвольные адреса как null, потому что Linux сообщал siginfo_t.si_addr == 0. Повторная проверка фактического исходного регистра исправила классификацию, а обновление отправили Samsung.

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

QMv1 породил множество ошибок, но был непоследовательно достижим в современных контекстах. Число сбоев росло от QG1.0 к QG1.1 и QG2.0 вместе со сложностью. Один QG2.0 добавил примерно столько же ошибок, сколько QG1.0 и QG1.1 вместе; окончательный эксплойт использовал ошибку QG2.0.

Что дальше?

Проверка входных файлов категории записи в приложениях Samsung обнаружила сбой «Моих файлов» с PC 0x4a4a4a4a4a4a4a, достигнутый из process_run_dec_check_buffer и QmageRunLengthDecodeCheckBuffer_Rev11454_141008. Контролируемые входные байты превратились в указатель инструкций — серьёзное свидетельство возможности произвольного выполнения кода.

Для завершения эксплойта оставалось выбрать лучший примитив повреждения, найти надёжно перекрываемые объекты кучи, удалённо обойти ASLR через преимущественно односторонний канал MMS и сохранять Messages живым при повторных ошибках. Часть 3 начинает построение эксплойта.

• выделения одного размерного класса обычно размещаются рядом;

• метаданные аллокатора хранятся отдельно, поэтому переполнение одного выделения напрямую достигает данных приложения;

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

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

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

Чтобы понять поведение выделений декодера, в тестовую среду добавили параметр -l, журналирующий каждую операцию malloc, calloc, realloc и free:

Поиск подходящей ошибки

Сначала 174 сбоя записи сократили до 23 уникальных мест перезаписи, затем до 17 после исключения старого формата QMv1. Остались четыре привлекательных класса.

Первый вариант наиболее гибок. Хранилище пикселей выделяется раньше всего, его размер управляется размерами изображения, а переполнить его могут и пути RLE, и пути zlib. Поэтому оно способно повредить Bitmap, выделенный непосредственно следом, а также более поздние объекты декодера.

Выбранный образец QG2.0 запускает переполнение в QuramQmageGrayIndexRleDecode. В исходном сбое изображение 40 × 7 при четырёх байтах на пиксель создаёт 1120-байтный пиксельный буфер. За ним следуют Bitmap, 24-байтное выделение сжатых входных данных и 4120-байтный контекст RLE:

Настольная тестовая среда сообщает о 104-байтном Bitmap, но реализация Android имеет размер 160 байт. Трассировка Frida на устройстве подтвердила настоящую последовательность:

Пиксельное выделение выполняет android::Bitmap::allocateHeapBitmap:

При выборе размеров 10 × 4 хранилище пикселей имеет ровно 160 байт. Оба выделения попадают в один размерный класс jemalloc. На проверенном устройстве их адреса отличались ровно на 0xA0 байта, поэтому переполнение первого выделения немедленно достигает Bitmap. Такое размещение математически не гарантировано при каждом запуске, но достаточно надёжно для эксплуатации.

Встречайте объект Bitmap из Android

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

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

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

Для воспроизводимых экспериментов файл Qmage доказательства концепции переписали как исходник NASM. Псевдоинструкции db, dw и dd в NASM позволяют легко изменять двоичные поля, сохраняя комментарии и структуру. Восстановить формат помогли отладочные символы, извлечённые из старых сборок libQmageDecoder.so во время работы над частью 1.

Тестовый файл содержит:

1. Заголовок QG1.2, эквивалентный QG2.0, с размерами 4 × 10.

2. Сжатую zlib таблицу цветов, заполненную байтами 0x41.

3. Обязательный маркер FF 00, за которым следует тип сжатия RLE 06.

4. Поток RLE, создающий 161–320 байт: 160 байт для пиксельного выделения и ещё 1–160 байт для соседнего объекта.

5. Завершающий маркер FF 00.

Qmage не использует простую схему RLE в стиле BMP. Символы init_process_run и process_run_dec указывают на MELCODE. Для эксплуатации несжатую последовательность всё равно можно обернуть небольшими префиксом и суффиксом. Например, восьмибайтная строка ABCDEFGH превращается в:

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

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

В первом эксперименте только начальный восьмибайтный указатель таблицы виртуальных функций перезаписывается значением AAAAAAAA. Затем уничтожение bitmap вызывает сбой при разыменовании контролируемого указателя:

Соответствующие инструкции:

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

Вызов freeFunc

Элемент External объединения хранилища пикселей содержит ещё одну привлекательную цель:

Bitmap::~Bitmap вызывает её напрямую:

Другие типы хранилища предоставляют произвольный munmap вместе с close, произвольный free или ещё один виртуальный вызов. freeFunc особенно полезна в одноразовой атаке, поскольку вызывает контролируемый адрес с двумя контролируемыми 64-разрядными аргументами.

Есть одно осложнение: сам деструктор достигается через таблицу виртуальных функций по нулевому смещению. Поэтому перед использованием более глубокого поля freeFunc линейная перезапись должна восстановить исходную таблицу, для чего необходимо знать базу libhwui.so. В тесте объект заполнили значением 0x41 и исправили следующие поля:

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

• fRefCnt: 1;

• mPixelStorageType: External (0);

• address: 0xaaaaaaaaaaaaaaaa;

• context: 0xbbbbbbbbbbbbbbbb;

• freeFunc: 0xcccccccccccccccc.

Полученный сбой доказывает контроль над PC, X0 и X1:

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

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

Большинство опубликованных обходов ASLR работает через интерактивный канал. Эксплойт браузера может прочитать утёкший указатель в JavaScript, эксплойт ядра — вернуть данные пользовательскому режиму, а сетевая служба — отправить адрес клиенту. MMS в основном односторонний, поэтому удалённый отправитель не может просто получить 64-разрядный указатель.

Самуэль Гросс столкнулся с тем же ограничением при эксплуатации iMessage через CVE-2019-8641. Уведомления о доставке предоставили однобитный канал, способный сообщить результат оракула ASLR. MMS также поддерживает уведомления о доставке, а Samsung Messages может показать, пережил ли процесс обработку сообщения. Если повреждённый объект способен преобразовать доступность адреса для чтения в результат «сбой/нет сбоя», этот результат можно вернуть удалённо.

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

Перезапись всего Bitmap значением 0x41 вместо этого вызывает более ранний сбой через mInfo.fColorSpace:

Направление поля в доступную для чтения заполненную нулями память всё равно вызывает abort, поскольку реализация цветового пространства Java отклоняет нулевую передаточную функцию:

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

Чистый стек Java показывает, где Samsung Messages преобразует входящее изображение:

Samsung Messages имеет закрытый исходный код, поэтому /system/priv-app/SamsungMessages_11/SamsungMessages_11.apk декомпилировали с помощью jadx, чтобы исследовать эти пути.

Время жизни Bitmap

Bitmap проходит три важных этапа:

1. ImageUtil.loadBitmapFromStream создаёт его через BitmapFactory.decodeStream.

2. ImageUtil при необходимости масштабирует его, когда размеры превышают целевые.

3. com.samsung.android.messaging.ui.model.l.at.a преобразует его в ARGB_8888, если это необходимо.

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

• fWidth (+0x0c) = 1;

• fHeight (+0x10) = 1;

• mInfo.fWidth (+0x60) = 1;

• mInfo.fHeight (+0x64) = 1.

Чтобы пройти проверки rowBytes в SkBitmap::setInfo, fRowBytes (+0x20) устанавливается в 0x1000. mInfo.fColorSpace (+0x58) задаётся null, чтобы не разыменовываться. Затем путь достигает:

swizzle_or_premul требует, чтобы тип цвета источника был RGBA_8888 (4) или BGRA_8888 (6). Java уже отклонила первый вариант при проверке Bitmap.Config, поэтому mInfo.fColorType (+0x68) устанавливается в 6.

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

Его исходные значения поступают непосредственно из повреждённого объекта:

Для каждой строки Skia читает width * 4 байта по контролируемому указателю, а затем увеличивает его на fRowBytes. Значения пикселей не влияют на поток управления, поэтому допустимы любые доступные для чтения данные.

Два последних изменения превращают это в оракул:

• fPixels (+0x18) = начало проверяемого диапазона адресов;

• mInfo.fHeight (+0x64) = число проверяемых страниц.

При ширине 1 и шаге строки 0x1000 Skia читает по четыре байта с каждой страницы непрерывного диапазона. Если все страницы доступны для чтения, преобразование завершается и приложение выживает. Если любая страница недоступна, процесс падает на первом недоступном адресе.

Установка fPixels в 0xcccccccccccccccc подтверждает примитив:

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

Установка fPixels в 0x7fdfb10000, за восемь страниц до конца, а mInfo.fHeight в 10 даёт:

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

Итоги

Результаты псевдо-ASAN привели к линейному переполнению кучи при декомпрессии RLE в Qmage. Если согласовать размеры пиксельного буфера и android::Bitmap, полезное поведение jemalloc помещает объект непосредственно после уязвимого выделения и позволяет надёжно повредить его, не сталкиваясь со встроенными метаданными аллокатора.

Повреждённый Bitmap предоставляет два примитива потока управления: произвольный виртуальный вызов и прямой контролируемый вызов функции с двумя аргументами через freeFunc после определения адреса libhwui.so. Путь преобразования пикселей также предоставляет оракул ASLR, читающий одно слово с каждой страницы и преобразующий доступность в результат «сбой/нет сбоя».

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

В 2019 году было обнаружено и раскрыто 20 уязвимостей нулевого дня из реальных атак. Наш учёт ограничен целями и областями активных исследований Project Zero; подробнее об охвате сказано здесь. Число примерно соответствует среднему за 2014–2017 годы, тогда как в 2018 году обнаружений было необычно мало. Project Zero начала отслеживание только после основания в июле 2014 года, поэтому для приблизительной оценки показатель 2014 года удвоен.

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

Все эксплойты 2019 года подробно перечислены в таблице Project Zero.

Уязвимости по разработчикам

Распространённый способ анализа — посмотреть, кого затронули проблемы. Разбивка 2019 года показывает, что почти у каждого крупного разработчика платформ обнаружилось по несколько атак, но различия велики. По данным кажется, что продукты Microsoft атакуют примерно в пять раз чаще Apple и Google. Однако iOS и Android составляют огромную долю устройств мира.

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

Подробный разбор Microsoft

В 2019 году в продуктах Microsoft обнаружили 11 эксплойтов — более половины общего числа. Это единственная платформа с достаточно большой выборкой для более глубокого анализа.

Из 11 эксплойтов только четыре были замечены против новейшей версии Windows. Остальные нацеливались на старые выпуски, например Windows 7 от 2009 года. Из четырёх, работавших в актуальной Windows, три атаковали Internet Explorer, который не является браузером по умолчанию Windows 10, но включён ради совместимости. Итак, 10 из 11 проблем Microsoft предназначались для устаревшего ПО.

Шесть из 11 атаковали компонент Win32k — часть ядра оконной подсистемы, исторически популярную цель. В Windows 10 Microsoft вложилась в сокращение его поверхности. По обнаруженным данным ни один из шести эксплойтов Win32k не применялся против последней версии Windows 10, а две уязвимости, CVE-2019-0676 и CVE-2019-1132, затрагивали только Windows 7.

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

Уязвимости Internet Explorer JScript CVE-2019-1367 и CVE-2019-1429

Хотя цель статьи не в подробном разборе каждой уязвимости 2019 года, нельзя не обсудить JScript в Internet Explorer. CVE-2019-1367 и CVE-2019-1429, а также CVE-2018-8653 от декабря 2018-го и CVE-2020-0674 от февраля 2020-го — варианты одной ошибки. По данным группы анализа угроз Google (TAG), все четыре применял один злоумышленник.

Наш анализ первопричины содержит подробности. Класс ошибки — переменная JScript, не отслеживаемая сборщиком мусора. Несколько экземпляров Иван Фратрич из Project Zero обнаружил в январе 2018 года. В декабре TAG увидела этот класс в реальной атаке как CVE-2018-8653. В сентябре 2019 года нашли ещё один эксплойт. Проблему «исправили» как CVE-2019-1367, но патч в действительности её не устранил, и атакующие продолжили использовать исходную ошибку. Одновременно Иван Фратрич нашёл вариант (P0 1947). И вариант, и исходную проблему исправили как CVE-2019-1429. В январе 2020 года TAG обнаружила ещё один образец из-за повторно неполного патча Microsoft; его устранили как CVE-2020-0674.

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

Повреждение памяти

63% эксплуатировавшихся в 2019 году уязвимостей относятся к повреждению памяти, половина из них — использование после освобождения. Их популярность не нова. Основополагающая работа о повреждении стека «Smashing the Stack for Fun and Profit» вышла в 1996 году. Но интересно, что почти две трети обнаруженных 0-day по-прежнему эксплуатируют память, несмотря на множество исследований других классов, например логических и компиляторных ошибок. Подчеркнём: две трети обнаруженных. Я не знаю, является ли доля ложной, но проверить нельзя, поскольку повреждение памяти искать проще. Из-за распространённости и меньшей надёжности по сравнению с логическими ошибками это может быть ещё одним смещением. Типы повреждения внутри платформ похожи и мало меняются: UAF десятилетней давности выглядит примерно как современный, поэтому мы могли просто научиться лучше их выявлять. Логические и архитектурные ошибки редко похожи друг на друга, поскольку используют конкретный недостаток конкретного компонента, что усложняет обнаружение.

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

Дополнительные мысли об обнаружении

По-прежнему актуальны вопросы из первой статьи команды: «Какова доля обнаружения эксплойтов нулевого дня?» и «Сколько применяется незаметно?»

Индустрия может анализировать только обнаруженные случаи, а не все использованные. По данным нельзя добросовестно утверждать, что Windows атакуют в 11 раз чаще Android. Скорее, сообщество намного чаще обнаруживает атаки Windows. Исторически первые антивирусы и средства поиска создавались для Microsoft Windows, а затем методы продолжали развиваться. Инструменты строит и Microsoft, и сторонние компании. На других, особенно мобильных платформах такого разнообразия нет, поэтому вероятность обнаружения ниже. Большое направление роста — поиск на платформах кроме Windows и уровень доступа, который разработчик предоставляет защитным средствам.

Кто обнаруживает?

Один исследователь, Клеман Лесинь из TAG Google, указан автором обнаружения семи из 21 уязвимости 2019 года на четырёх платформах: Apple iOS (CVE-2019-7286, CVE-2019-7287), Google Chrome (CVE-2019-5786), Microsoft Internet Explorer (CVE-2019-0676, CVE-2019-1367, CVE-2019-1429) и Microsoft Windows (CVE-2019-0808). Иначе говоря, без Клемана и команды было бы найдено на треть меньше. Вторая организация, Kaspersky Lab, обнаружила четыре: CVE-2019-0797, CVE-2019-0859, CVE-2019-13720 и CVE-2019-1458. Две организации отвечают более чем за половину всех обнаружений года. Если более половины находит лишь пара участников глобального сообщества, это тревожный признак распределения ресурсов. До уверенности в обнаружении большинства применяемых эксплойтов ещё далеко.

Из 20 уязвимостей только одна, CVE-2019-0703, включала разработчика целевого продукта среди авторов обнаружения, и даже она также приписана внешнему исследователю. Это удивительно: разработчик платформы лучше всего расположен для поиска благодаря телеметрии, журналам, возможности встроить обнаружение и получаемым «наводкам». Возникает вопрос: команды с максимальным доступом не выделяют ресурсы или находят, но не раскрывают внутренние обнаружения? Оба варианта далеки от идеала. Для закрытых мобильных платформ ситуация особенно тревожна, поскольку внешним специалистам трудно попасть внутрь и увидеть эксплуатацию.

«Тайная» регистрация 0-day

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

Обнаружение на мобильных платформах

Особенно нуждаются в развитии iOS и Android. В 2019 году для всех мобильных платформ обнаружили лишь три уязвимости: две iOS (CVE-2019-7286, CVE-2019-7287) и одну Android (CVE-2019-2215). Между тем мобильными телефонами пользуются миллиарды, а по данным Zerodium эксплойты Android и iOS стоят вдвое или ещё дороже аналогичных настольных. Мы знаем, что их создают и применяют, просто не находим. Из-за «огороженного сада» iOS и песочниц приложений обеих систем сторонним защитным решениям особенно трудно развёртываться. Те же функции, которые критически важны для пользователей, мешают стороннему обнаружению на устройстве. Поэтому пользователи и сообщество зависят от активного и прозрачного поиска разработчиков. Ключевой вопрос: как побудить их приоритизировать эту работу?

Ещё один интересный результат: CVE-2019-2215 — первая отслеживаемая нами уязвимость нулевого дня, нацеленная на Android. До неё ближе всего была CVE-2016-5195 для Linux. Но единственную Android-ошибку 2019 года и всего периода с 2014-го обнаружили по документам, а не по образцу эксплойта. Значит, в 2019, 2018, 2017, 2016, 2015 и половине 2014 года ни одного образца не обнаружили или как минимум публично не раскрыли. Знание наступательной отрасли говорит, что это не означает отсутствия использования. Обнаружение недостаточно, эксплойты остаются неизвестными, ошибки — неисправленными, а пользователи и защитники не могут принять дополнительные меры. В 2020 году Project Zero сосредоточится на новых методах поиска атак на iOS и Android.

Обнаружение на других платформах

За тот же период ни одной уязвимости не обнаружили на других популярных платформах, например Linux, Safari и macOS. Несмотря на отсутствие публичных случаев, можно уверенно считать их интересными целями по числу пользователей, вакансиям наступательных специалистов и разговорам с исследователями. Если атакуют OfficeScan Trend Micro, то тем более гораздо более распространённые продукты. Это снова возвращает нас к обнаружению. Но некоторым платформам для успешной эксплуатации могут не требоваться 0-day. Например, эта статья описывает цепочки iOS с публично известными n-day WebKit. Без полных данных нельзя уверенно определить объём эксплуатации по платформам.

Заключение

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

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

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

Уязвимая функция pmap_remove_options_internal() — процедура PPL. XNU вызывает её через pmap_remove_options(), проверяющую аргументы до пересечения границы PPL. Процедура удаляет предоставленный диапазон виртуальных адресов из карты физической памяти процесса:

Фактические записи таблицы трансляции (TTE) удаляет pmap_remove_range_options(). Она получает указатели на начало и конец диапазона в таблице трансляции третьего, то есть листового, уровня:

Вычисляя эти указатели, pmap_remove_options_internal() предполагает, что переданный виртуальный диапазон не пересекает границу таблицы трансляции L3:

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

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

После очистки записей pmap_remove_options_internal() делает недействительными кэшированные трансляции переданного виртуального диапазона:

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

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

Обход выполняется так:

1. Вызвать функцию ядра cpm_allocate() и выделить две смежные физические страницы A и B.

2. Вызвать pmap_mark_page_as_ppl_page(), поместив A и B в начало ppl_page_list, чтобы они стали доступны для повторного использования в качестве таблиц страниц.

3. Вызвать ошибки страниц для виртуальных адресов P и Q. A и B становятся таблицами трансляции L3 для P и Q. Виртуально P и Q несмежны, но их TTE расположены рядом в физической памяти.

4. Запустить поток с бесконечным циклом, закреплённый за одним ядром процессора. Он постоянно читает страницу Q, поддерживая её запись TLB активной.

5. Вызвать pmap_remove_options() для удаления двух страниц начиная с P — виртуального диапазона, не содержащего Q. Уязвимость удалит TTE и P, и Q, но сделает недействительной только запись TLB для P.

6. Снова вызвать pmap_mark_page_as_ppl_page(), поместив физическую страницу Q в начало ppl_page_list.

7. Вызвать ошибку страницы по виртуальному адресу R. Физическая страница Q будет повторно использована как таблица L3 для R, хотя поток всё ещё удерживает устаревшую трансляцию TLB для Q.

8. Через устаревшую трансляцию записать в страницу Q TTE L3, отображающую саму Q с доступом на запись.

9. С помощью этого самоотображения изменять таблицы страниц после исчезновения устаревшей записи TLB.

Уязвимость была зарегистрирована как проблема Project Zero 2035 и исправлена в iOS 13.6. К отчёту приложен PoC, отображающий произвольные физические адреса в EL0. Более глубокий разбор неправильной инвалидации TLB приведён в статье Янна Хорна «Берём страницу из книги ядра».

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

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

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

CVE-2020-6387 затрагивает обработку прямой коррекции ошибок расширения синхронизации видео. При восстановлении пакетов FEC копирует входящие RTP-пакеты и очищает поля синхронизации:

Значение kPacerExitDeltaOffset равно семи. Код очищает байты с 7-го по 12-й в расширении, не проверяя, что его длина равна 13 байтам или что в пакете осталось столько данных. Это предоставляет атакующему запись до шести нулевых байтов со смещением до семи байтов за пределами буфера кучи переменного размера.

Вторая ошибка предоставляет более широкий выбор размера выделения, невыровненную запись и некоторое управление смещением. Первая записывает больше байтов, но требует 64-разрядного выравнивания и нацелена на фиксированный размер. Ни один примитив не выглядит идеальным: CVE-2020-6389 записывает только небольшие целые числа, а CVE-2020-6387 — только нули.

Изменение указателя инструкций

Современный Android использует jemalloc — распределитель с блоками без встроенных заголовков кучи, поэтому повреждение метаданных распределителя невозможно. Я собрала WebRTC для Android с символами, загрузила её в IDA и исследовала типы объектов, которые могли либо улучшить примитив записи, либо непосредственно повлиять на поток управления.

Увеличить длину с помощью CVE-2020-6389 оказалось неудобно. Многие значения длины имеют 32 бита, но ошибка перезаписывает целый 64-разрядный слот, повреждая соседнее поле. Ненулевую длину можно выбрать целью только в позиции, выровненной по 64 битам. Кроме того, перезапись выполняется на позднем этапе обработки пакета, когда многие временные объекты уже использовались в последний раз. CVE-2020-6387 способна только уменьшить длину, поскольку записывает нули.

Для поиска неожиданных эффектов я многократно запускала CVE-2020-6389 в Android. Примерно в одном из 20 сбоев указатель инструкций содержал значение, явно загруженное из кучи. После переполненной области был выделен StunMessage. Его первое поле после таблицы виртуальных функций — вектор:

Вектор libc++ начинается с двух указателей:

Запись за границами заменила __end_ небольшим 16-разрядным целым числом. Итерация по вектору начинается с __begin_ и увеличивает указатель до достижения __end_; при повреждённом конечном указателе уничтожение выходит за пределы выделения. Поскольку вектор содержит виртуальные объекты StunAttribute, деструктор в итоге выполняет виртуальный вызов через память за границами. Именно этот вызов объясняет управляемый на вид указатель инструкций.

Обычно один участник WebRTC не может напрямую отправлять пакеты STUN другому: каждый взаимодействует со своим сервером STUN. Филипп Ханке из webrtchacks предложил использовать подконтрольный атакующему TCP-сервер как кандидата ICE. Тогда оба участника взаимодействуют через этот сервер, включая трафик STUN, что позволяет атакующему ретранслировать специально сформированные сообщения.

Эксплойту нужны управляемые данные после выделения вектора. Обычные сообщения STUN содержат мало атрибутов и создают буферы вектора размером 32 или 64 байта в активно используемых классах размеров. Вместо этого я отправляла сообщения со 128 атрибутами, создавая буфер вектора размером 1024 байта в сравнительно спокойном классе jemalloc. Множество таких сообщений STUN чередовалось с RTP-пакетами размером 1024 байта, содержащими нужный указатель, и пакетами, запускающими уязвимость. Это приводило к виртуальному вызову по выбранному указателю примерно в одной из пяти попыток — достаточно, чтобы перейти к исследованию ASLR.

Взлом ASLR

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

Марк Бранд предложил использовать CVE-2020-6387, чтобы обнулить младшие байты указателя на исходящие данные. Усечённый указатель мог бы ссылаться на соседнюю память кучи и заставить WebRTC передать данные за пределами предполагаемого пакета. SendPacketMessageData и DataReceivedMessageData выглядели многообещающе, поскольку помещают исходящие RTP-данные в очередь в CopyOnWriteBuffer, первым полем которого является указатель со счётчиком ссылок на rtc::Buffer.

rtc::Buffer имеет приблизительно следующую структуру:

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

Повторное использование освобождённого rtc::Buffer со специально замещённым нижележащим выделением также оказалось ненадёжным. Объект имеет размер 36 байт и занимает 48-байтовый класс jemalloc. Последовательные объекты имеют следующие адреса:

Обнуление младшего байта указателей на буферы с 0 по 5 попадает в блок, а та же операция для буфера 6 — нет, поскольку 48 не делит 256 без остатка. Даже когда уязвимость затрагивает нужный объект данных в очереди, лишь около трети усечённых адресов определяют действительный rtc::Buffer. Вероятность попасть в сам объект была ниже десяти процентов, поскольку WebRTC создаёт множество выделений похожего размера. Замедление TCP-соединения дольше сохраняло объекты в очереди, но не делало полную цепочку практичной; организация освобождённых буферов и замещение их нижележащих данных добавляли ещё больше неопределённости.

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

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

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

NowSMS может работать как сервер SMS/MMS, шлюз WAP Push Proxy или MMSC. Для этого исследования важна возможность отправлять сообщения через локально подключённый GSM-модем или работающий в его роли телефон Android. Система предоставляет веб-интерфейс, HTTP API и API разработчика для PHP, Java и .NET.

Отправителем служил Samsung Galaxy A50, работавший как модем в режиме Remote Direct. Его подключили к локальной сети по Ethernet, чтобы исключить обрывы беспроводной связи. Целевой Galaxy Note 10+ был соединён с рабочей станцией по USB для доступа к оболочке и захвата экрана. Оба устройства оставались включёнными в зоне с уверенным покрытием сотовой сети.

Создание необработанного PDU MMS

MMS появился примерно в 2001–2002 годах и документирован главным образом для сетевых операторов. Здесь важна часть MM1 — протокол между телефоном и его центром Multimedia Messaging Service Centre (MMSC).

MMS — двоичный объект с MIME-типом application/vnd.wap.mms-message. Он содержит обязательные и необязательные заголовки, за которыми могут следовать составные медиафайлы: текст, изображения, аудио или видео. Двоичное представление определено в OMA-TS-MMS_ENC-V1_3-20110913-A.pdf (файл в files/OMA-TS-MMS_ENC-V1_3-20110913-A.pdf).

Простое описание исходника NowSMS выглядит так:

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

Начало полученного файла содержит закодированные заголовки, текстовые значения заголовков, имена MIME-объектов, а затем байты вложений:

Корректные MMS обычно включают разметку SMIL, управляющую представлением, но Samsung Messages принимает медиафайлы и без неё. Что важнее, MIME-типы вложений задаются отдельно от их содержимого. Поэтому файл Qmage можно пометить как image/jpeg, доставить как изображение и автоматически декодировать как bitmap.

Отчёты о доставке MMS

Отчёты о доставке существуют с MMS 1.0. Отправитель запрашивает подтверждение, устанавливая X-Mms-Delivery-Report в yes, что представлено байтами 86 81. Если класс сообщения равен auto, поле вместо этого должно быть no.

Google Messages предоставляет отчёты о доставке SMS, но не MMS. Samsung Messages поддерживает их в разделе Настройки > Дополнительные настройки > Мультимедийные сообщения > Показывать при доставке.

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

Более подробный взгляд на MM1

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

1. Отправитель передаёт M-send.req через HTTP POST.

2. MMSC отправляет получателю уведомление WAP Push.

3. Samsung Messages автоматически выполняет HTTP GET сериализованного MMS.

4. Клиент разбирает и сохраняет сообщение.

5. Он подтверждает успешное получение с помощью M-notifyresp.ind через HTTP POST.

6. MMSC возвращает отправителю отчёт M-delivery.ind.

Samsung Messages разбирает внешние медиафайлы до завершения этапа 5. Некорректный Qmage может вызвать сбой процесса после GET, но до M-notifyresp.ind. Тогда MMSC не считает сообщение доставленным и не отправляет немедленного отчёта.

Обычное сообщение создаёт оба запроса в logcat:

Подтверждение начинается примерно через 1,5 секунды после получения тела сообщения. Qmage, вызывающий сбой, показывает только GET:

До выполнения POST декодер вызывает ошибку:

NowSMS декодирует входящий успешный отчёт в файл .HDR в каталоге MMS-IN:

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

У наблюдавшихся операторов срок действия по умолчанию составлял 48 часов и настраивался с помощью X-Mms-Expiry в диапазоне от одной минуты до 48 часов. Эксплойт не ждёт истечения: отсутствие отчёта о доставке через 30 секунд после отправки рассматривается как сбой.

В сочетании с проверкой адресов из части 3 и стабильным расположением кода и данных Android Zygote при перезапусках приложений это создаёт удалённый однобитный оракул ASLR. Множество сбоев позволяет раскрывать полные адреса по одному решению за раз.

Дополнительные соображения о надёжности оракула

Побочный канал надёжен, когда оба телефона сохраняют хорошую связь с MMSC. Слабейшее место — расположение кучи: примитив предполагает соседство двух последовательных 160-байтных выделений jemalloc, пиксельного буфера и android::Bitmap. Бакет 129–160 байт также используется посторонними объектами Samsung Messages.

Каждый запрос может начинаться с чистой кучи, если сначала безусловно аварийно завершить приложение. Ложный результат оракула уже вызывает сбой, поэтому явные сбросы нужны только перед первым запросом и после истинного результата. Подойдёт любой детерминированно некорректный Qmage. Эксплойт использует образец, передающий в malloc отрицательный размер, получающий null и разыменовывающий его.

Это повысило оценочную точность на Galaxy Note 10+ выше 99%. На других устройствах, выпусках Android, с иной историей сообщений и включёнными функциями могут потребоваться повторные проверки и порог уверенности вместо доверия одному наблюдению.

ActivityManager и ограничение частоты сбоев в Android

После двух быстрых сбоев Samsung Messages перезапускается нормально:

Третье входящее MMS отклоняется:

На этом этапе атакующий не может достичь Qmage, а жертва не может получать SMS/MMS до ручного открытия Messages. isBadProcessLocked() в ActivityManager проверяет присутствие процесса в mBadProcesses:

handleAppCrashLocked() помечает приложение как плохое, если два сбоя происходят слишком близко:

Интервал равен одной минуте:

Поэтому атака должна гарантировать как минимум 60 секунд между сбоями. Истинная проверка требует последующего сбрасывающего MMS; ложная сама сбрасывает процесс.

Общего ограничения числа сбоев нет, поэтому медленная атака может продолжаться бесконечно. Восьмичасовое ночное окно теоретически допускает около 480 проверок.

Ещё одно осложнение — источник времени:

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

Были определены три бесшумные техники:

• MMS с пустым вложением text/plain тратит время на обработку, а затем вызывает необработанное исключение Java до уведомления; это исправили в Samsung Messages 11.1.0.61;

• MMS примерно со 140 КБ текста или больше тратит несколько секунд на создание уведомления, но завершается ошибкой до воспроизведения звука;

• SMS длиннее 5180 символов приходит в 34 сегментах; телефон получает примерно один сегмент в секунду, отказывается от сборки после 33 и увеличивает uptime примерно на 35 секунд без уведомления.

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

Итоги

Мы построили реалистичную для оператора тестовую среду MMS, изучили поток запросов MM1 и двоичную инкапсуляцию и программно запросили отчёты о доставке. Поскольку Samsung Messages разбирает вложения до отправки M-notifyresp.ind, наличие отчёта показывает, вызвал ли некорректный Qmage сбой процесса. Вместе с проверкой памяти из части 3 это образует работоспособный, но медленный оракул ASLR.

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

Следующей находкой стала CVE-2020-6514 — необычная ошибка интеграции. usrsctp идентифицирует конечные точки собственного транспорта парой значений void *. Она никогда не разыменовывает их, но включает числовые значения в пакеты протокола. WebRTC передаёт адрес своего экземпляра SctpTransport, поэтому каждое соединение SCTP раскрывает удалённому узлу указатель кучи. Самого по себе этого недостаточно: Android не показал надёжной корреляции между адресом кучи и загруженной библиотекой.

Третья ошибка обнаружилась в обработке ASCONF. Код отклоняет слишком большой параметр и возвращается, но освобождает слишком маленький буфер подтверждения без возврата:

Затем m_ack используется после освобождения. В новых версиях usrsctp и WebRTC проблема уже была исправлена, а изначально Марк Водрич сообщил о ней как об ошибке 376 19 сентября 2019 года.

Раскрытие памяти с помощью ошибки 376

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

Позднее обработка ASCONF добавляет освобождённое подтверждение в исходящую очередь:

Если выделение заместить контролируемыми данными, у которых mh_data указывает на интересную память, путь подтверждения отправит эту память удалённому узлу. Указатель кучи, раскрытый CVE-2020-6514, сразу даёт цель: объект SctpTransport содержит указатель на таблицу виртуальных функций и потому раскрывает базу библиотеки WebRTC.

Первая попытка повторно занять память использовала удерживаемые пакеты RTP того же размера. Видеопакеты остаются в очереди до сборки полного кадра, поэтому отсутствие конца кадра создаёт множество долгоживущих выделений. К сожалению, OpenSSL также выделяет объекты этого размерного класса. Если один из них занимал освобождённый mbuf, записи usrsctp оставляли OpenSSL в невосстановимом цикле, не позволяя создавать новые соединения и не вызывая чистого сбоя.

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

Немногие выделения usrsctp имеют удалённо контролируемые размеры. Лучший кандидат — поставленный в очередь запрос сброса потока данных:

К счастью, next_resp перекрывает mbuf.mh_next и имеет совместимый тип указателя, поэтому обход не завершается сразу ошибкой. Менее удобно то, что перекрывающие mh_data значения — это порядковый номер сброса и transmission sequence number (TSN), и оба проверяются.

Порядковый номер сброса должен быть равен исходному значению соединения и младшим 32 битам раскрытого указателя SctpTransport. Поддельный COOKIE_ECHO может установить необходимый номер до UAF. TSN должен равняться старшим 32 битам указателя и одновременно считаться находящимся впереди накопленного TSN. Поскольку старшая половина меньше 0x80, сравнение порядковых номеров даёт желаемый результат только при установленном бите 31 младшей половины — примерно в половине расположений ASLR.

Повторная неудача неприемлема, поскольку расположение Android остаётся стабильным до перезагрузки. Фрагменты FWD_TSN решают проблему, продвигая накопленный TSN до 4096 шагов за раз. Отправка множества фрагментов в нескольких плотно упакованных пакетах устанавливает бит 31 за секунды. После этого проверка выполняется независимо от исходного адреса кучи.

Цель возвращает байты из SctpTransport, включая таблицу виртуальных функций, раскрывая образ WebRTC. Второе применение той же утечки читает элемент malloc из Global Offset Table по фиксированному смещению относительно образа. Поскольку malloc находится в libc Android, её адрес даёт более стабильную базу системной библиотеки для приложений, по-разному собирающих или компонующих WebRTC.

Перемещение указателя инструкций — снова

После регистрации CVE-2020-6514 Янн Хорн заметил, что указатель собственного транспорта также позволяет управлять выполнением. Для обычных исходящих пакетов usrsctp выбирает адрес из состояния соединения; при обработке COOKIE_ECHO она принимает адрес, переданный в подписанном cookie. WebRTC преобразует этот адрес обратно в SctpTransport * и выполняет для него виртуальные вызовы.

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

Тот же предсказуемый генератор создаёт значение, раскрываемое в начальном рукопожатии SCTP. Проверяя через srand каждый возможный PID от 0 до 70 000, сценарий восстанавливает PID цели по наблюдаемому значению, а затем воспроизводит секрет cookie. Атакующий может подписать COOKIE_ECHO с любым адресом собственного транспорта.

WebRTC выполняет виртуальный вызов через этот указатель, как только usrsctp отправляет COOKIE_ACK. Это даёт более чистый примитив указателя инструкций, чем техника RTP, и использует ту же функцию SCTP, которая уже нужна для раскрытия ASLR, увеличивая число приложений, к которым применима цепочка.

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

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

SctpTransport содержит CopyOnWriteBuffer с именем partial_incoming_message_. usrsctp передаёт WebRTC крупные незавершённые фрагментированные сообщения, которая добавляет их в этот буфер до получения последнего фрагмента:

Сначала это казалось непригодным для самоссылочного поддельного объекта: базовый адрес становился известен лишь после записи неизменяемых данных. CopyOnWriteBuffer::Clear() обеспечивает недостающий порядок. Поставленная в очередь callback-функция удерживает ссылку на старые байты, поэтому очистка выделяет новый базовый буфер. Его указатель можно раскрыть до заполнения. Пока последующие данные не превышают наибольший очищенный размер, AppendData повторно использует это выделение.

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

Тестирование с последовательными значениями-маркерами привело к переходу через X8 при также контролируемом X21 и X23, указывающем на поддельный объект. libc Android содержит идеальный гаджет в do_nftw:

Установка X21 в system и размещение строки команды по смещению 0x30 заставляют гаджет вызвать system(command).

Окончательный эксплойт выполняет следующие шаги:

1. Восстановить удалённый PID по значению во фрагменте INIT и вывести секрет cookie.

2. Использовать ошибку 376 для чтения таблицы виртуальных функций SctpTransport.

3. Прочитать malloc из Global Offset Table WebRTC и вычислить базу libc.

4. Заполнить partial_incoming_message_ данными необходимого размера.

5. Очистить его, чтобы создать повторно используемое базовое выделение.

6. Прочитать адрес буфера partial_incoming_message_ из SctpTransport.

7. Прочитать адрес базовых данных из объекта буфера.

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

9. Отправить поддельный COOKIE_ECHO; WebRTC выполняет виртуальный вызов, достигает гаджета libc и вызывает system.

Теперь эксплойт работает в демонстрационном Android-приложении WebRTC. Часть 3 проверяет предположения на настоящих мессенджерах и их различающихся интеграциях WebRTC.

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

• system относительно malloc в Android libc;

• гаджет do_nftw относительно malloc;

• vtable WebRTC cricket::SctpTransport относительно записи malloc в Global Offset Table.

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

У proof-of-concept-скриптов есть важное ограничение: большинство операций чтения памяти работает, только когда в соответствующем указателе установлен бит 31. В части 2 объясняется, как повторяющиеся чанки FWD_TSN устраняют это ограничение, и в скриптах есть один пример, однако эта корректировка реализована не для каждого чтения. Для тестирования устройство перезагружалось до тех пор, пока WebRTC не загружался по подходящему адресу.

Android-приложения

Поиск APK из Google Play по специфичной для usrsctp строке обнаружил примерно 200 приложений с более чем пятью миллионами пользователей, в состав которых, по всей видимости, входил WebRTC. Их назначение можно разделить на четыре широкие категории:

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

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

• Браузеры: JavaScript предоставляет гибкую настройку WebRTC. Атакующему всё равно требуется убедить цель посетить страницу, запускающую одноранговое соединение, поэтому последствия аналогичны другим ошибкам повреждения памяти в renderer.

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

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

Список, составленный 18 июня 2020 года, выглядел так:

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

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

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

Signal

Signal стал первой целью, поскольку исходный код его интеграции ringrtc открыт. Сборка ringrtc и Signal с символами упростила настройку семи Frida-хуков. Эксплойт срабатывал примерно в 90% случаев и не требовал взаимодействия с пользователем: уязвимая версия устанавливала соединение WebRTC и принимала RTP/SCTP до ответа на входящий звонок.

Ошибка 376 зависит от того, займёт ли следующее выделение того же размера освобождённый объект; иногда гонку выигрывает другой поток. Сбой обычно приводит к падению процесса, который перезапускается без заметной ошибки интерфейса, хотя появляется пропущенный звонок. Для тестирования использовалась версия Signal 4.53.6 от 13 января 2020 года. В последующих выпусках были исправлены ошибка 376 и CVE-2020-6514, отключён достижимый код ASCONF, добавлено требование взаимодействия для неизвестных звонящих и начато удаление SCTP из пути обработки звонков.

Google Duo

Duo динамически компоновал почти неизменённую библиотеку libjingle_peerconnection_so.so. Функции были найдены в IDA и перехвачены по смещениям от экспортированного символа; смещение между vtable и GOT было скорректировано для Duo. Эксплойт работал без взаимодействия с пользователем, поскольку Duo также устанавливал соединение WebRTC до ответа.

Для тестирования использовалась версия 68.0.284888502.DR68_RC09, выпущенная 15 декабря 2019 года. Позднее ошибки были исправлены. Duo также изменил модель доступности: ранее произвольный звонящий мог связаться с Android-устройствами с Google Play Services, даже если Duo не был явно установлен, тогда как позднее потребовались настройка и наличие звонящего в контактах.

Google Hangouts

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

Facebook Messenger

Messenger использовал старую производную от WebRTC библиотеку librtcR11.so и отдельно скомпонованную библиотеку usrsctp. В старом классе транспорта, по-видимому, сохранялся аналог раскрытия указателя, а в usrsctp присутствовала ошибка 376. Однако Messenger настраивал каналы данных RTP и отклонял попытки переключиться на SCTP через SDP. Уязвимый путь был недостижим.

Viber

Процесс установления звонка в Viber не предоставлял конфигурацию SCTP, необходимую для цепочки. Этот proof of concept не мог его эксплуатировать.

VK

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

OK и TamTam

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

JioChat

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

Slack и ICQ

Проверенные пути обработки звонков не предоставляли необходимого доступа к SCTP, поэтому proof of concept не работал. Slack независимо подтвердила, что её сервис Calls не был затронут описанной цепочкой.

BOTIM

BOTIM был протестирован, но в исследованной конфигурации рабочую цепочку получить не удалось.

Другое приложение

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

Обсуждение Риск WebRTC

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

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

Обновление WebRTC

Ошибка 376 была исправлена в upstream в сентябре 2019 года, однако исправление включили только два из 14 приложений. У usrsctp отсутствовал формальный процесс публикации уведомлений о безопасности, поэтому исправление выглядело как обычное исправление ошибки и не попало в WebRTC до 10 марта 2020 года. Оно не было упомянуто в примечаниях о безопасности Chrome Stable, за которыми рекомендовалось следить интеграторам WebRTC.

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

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

Архитектура приложения

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

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

Заключение

Android-эксплойт объединял две ошибки, связанные с usrsctp. Он был полностью удалённым в Signal, Google Duo, JioChat и Mocha, а в VK, OK и TamTam требовал взаимодействия пользователя. Семь других проверенных мессенджеров фактически отключали путь SCTP, необходимый цепочке.

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

Ответы поставщиков

WebRTC заменил прямые идентификаторы-указатели SctpTransport непрозрачными идентификаторами, сопоставляемыми с действительными объектами, стал игнорировать неизвестные значения, исправил затронутые продукты Google и связался примерно с 50 приложениями и интеграторами. Он рекомендовал обновиться до ветки M85 или применить два соответствующих коммита.

Mail.ru сообщила, что немедленно начала обновлять VK, OK, TamTam и связанные продукты и развернула серверные средства защиты для всех пользователей в течение трёх часов после получения демонстрации эксплойта.

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

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

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

Абсолютные позиции меняются между загрузками, но отображения остаются плотно сгруппированными относительно друг друга. Особенно выделяется одна огромная непрерывная доступная для чтения область — теневая память Control Flow Integrity.

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

Линейный поиск с шагом 2 ГБ находит адрес внутри него за 2–36 проверок. Одна дополнительная проверка 1 ГБ до или после найденной точки позволяет отличить теневую память от меньших доступных для чтения отображений. Поскольку оракул проверяет диапазоны, двоичный поиск находит любую границу за 19 итераций. Таким образом, первоначальная привязка требует примерно 21–55 запросов.

По иронии судьбы сама libhwui.so не была защищена CFI, тогда как крупная доступная для чтения теневая область облегчала обход ASLR. Позднее Android изменил защиту неиспользуемых страниц теневой памяти, составлявших более 99% области, на PROT_NONE.

Поиск первых дешёвых гаджетов для эксплуатации: linker64

В тестовой сборке 168 модулей неизменно располагались выше теневой памяти CFI, а 54 — ниже. Все вероятные цели, включая libc и libhwui.so, находились в пределах 128 МБ от конца теневой памяти. Порядок загрузки библиотек рандомизируется с 2015 года, поэтому их индивидуальные смещения нестабильны.

Одна группа отличалась необычно низким разбросом: стек сигналов, страницы случайных данных и среды выполнения, окружающие /apex/com.android.runtime/bin/linker64.

linker64 — это интерпретатор, который ядро загружает первым; он аналогичен ld-linux-x86-64.so.2 и не подчиняется обычной рандомизации порядка библиотек. В нём есть обёртки системных вызовов, варианты execve и, что особенно полезно, __dl_popen:

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

В 4000 исследованных расположений база linker находилась через 107,94–108,80 МБ после конца теневой памяти либо через 104,05–108,40 МБ с учётом соседних доступных для чтения страниц. Начиная со 100 МБ после границы, эксплойт делает выборки с интервалом 1088 КБ, равным размеру отображённого диапазона linker64. Доступность выборки проверяется чтением 544 КБ с одной стороны, после чего девятишаговый двоичный поиск находит точный конец. Вычитание 0x11b000 даёт базовый адрес.

Поиск теневой памяти CFI вместе с linker64 занимал 38–75 запросов, в среднем 56,45, или примерно 40–80 минут.

__dl_popen достигала linker64 через convertMonotonic в коде журналирования Android.

Поиск libhwui.so в памяти

Прямой примитив android::Bitmap.mPixelStorage.external.freeFunc вызывает выбранную функцию с двумя контролируемыми аргументами, однако при линейной перезаписи необходимо восстановить исходную vtable объекта Bitmap. Для этого требуется базовый адрес libhwui.so.

Примерно 168 разделяемых объектов занимают около 100 МБ рядом с теневой памятью CFI в случайном порядке. Execute Only Memory (XOM) в Android 10 позволяет удалённо получать их отпечатки: доступные для чтения сегменты метаданных и данных окружают доступное только для исполнения, недоступное для чтения отображение кода.

libhwui.so — крупнейшая загруженная библиотека общим размером 7,94 МБ: 2,17 МБ доступной для чтения памяти, 5,59 МБ памяти только для исполнения, а затем ещё 180 КБ для чтения.

Алгоритм 1: базовый поиск отображённой области

Проверять по одной странице через каждые 2,17 МБ. Для каждой доступной страницы двоичным поиском найти конец X, а затем проверить:

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

Алгоритм 2: последовательная выборка страниц

Большинство отображений можно отклонить без девяти запросов для поиска границы. Продолжать выборку с интервалами 2,17 МБ и действовать, только когда результаты соответствуют [1, 0, 0]: одна доступная для чтения выборка, за которой следуют две недоступные. Лишь после этого выполнять поиск границы и проверку расположения.

Благодаря этому суммарная ожидаемая стоимость поиска linker64 и libhwui.so приблизилась к 100 проверкам.

Алгоритм 3: оптимизация Бойера — Мура

Карта выборок представляет собой двоичную строку. Сопоставление с конца шаблона, как в алгоритме Бойера — Мура, позволяет после несовпадения перепрыгивать через несколько позиций. При карте 110111100 для поиска 100 не требуется проверять каждую позицию: доступное для чтения значение на месте последнего нуля шаблона доказывает, что несколько соседних начальных позиций не могут совпасть.

Лучшая испытанная конфигурация делает выборку через каждый 1 МБ и ищет [1, 1, 0, 0, 0, 0, 0].

По сравнению с алгоритмом 2 максимальное значение снизилось со 120 до 64, а среднее — на 34%; при этом облегчённый режим достиг 100-процентной точности на корпусе.

Полная сборка обхода ASLR

Окончательная логика поиска CFI, linker64 и libhwui.so требовала 45–129 запросов, в среднем 85,91. При одном запросе в минуту обход завершается примерно за 1–2,5 часа. В исходной демонстрации использовался алгоритм 2, которому на конкретном расположении потребовалось 86 запросов; алгоритм 3 сократил бы тот же запуск до 75.

Переход к RCE

Зная адреса linker64 и libhwui.so, повреждённый bitmap может через mPixelStorage.external вызвать контролируемую функцию с двумя значениями. __dl_popen — идеальная цель, но её первый аргумент должен указывать на контролируемую атакующим ASCII-команду, а ни один указатель кучи ещё не раскрыт.

Гаджет write-what-where мог бы записать короткую команду в статическую память, однако две записи и заключительный вызов требуют трёх последовательных успешных переполнений без перезапуска приложения. Предпочтительнее примитив на основе одного MMS.

Правильное представление Heap и ошибочно интерпретированное представление объединения External перекрываются:

heap.address уже указывает на контролируемые пиксели и после смешения типов становится первым аргументом. Сложность состоит в том, чтобы линейным переполнением добраться до freeFunc, не уничтожив address.

Вызов функций со строковым аргументом Приём 1: неинициализированная freeFunc

Изменить mPixelStorageType с Heap на External, но остановиться на смещении 0x70. external.address сохранит указатель пикселей, context станет размером, а freeFunc сохранит байты, ранее находившиеся в выделенном блоке.

Кеш jemalloc для каждого размера позволяет заранее заполнить эти байты. При разборе таблицы цветов Qmage непосредственно перед выделением bitmap выделяются и освобождаются сжатый буфер, распакованный буфер и состояние zlib. Если сделать первые два буфера размером 129–160 байт и поместить нужный указатель по смещению 0x90, их память будет использована повторно:

Bitmap наследует подготовленную freeFunc, тогда как X0 по-прежнему указывает на контролируемый текст пикселей. Тест с 0x414141... дал следующий результат:

Приём 2: гаджет libwebp

Адрес пикселей также находится в поле Bitmap.fPixels по смещению 0x18. Встроенная в libhwui.so библиотека libwebp содержит:

Структуры удобно перекрываются:

Установить vtable bitmap в &g_worker_interface.Sync, счётчик ссылок — в 1, а 64-разрядное поле по смещению 0x10 — в желаемый PC. После этого 24-байтовое переполнение достигает Execute, которая вызывает данный PC с X0, указывающим на строку пикселей.

Корректировка второго аргумента

В отличие от system, __dl_popen требует, чтобы X1 содержал допустимый указатель mode. Оба строковых приёма оставляют в X1 небольшое недопустимое целое число. Это исправляет промежуточная функция Qmage ReadStreaEndError.

Она вызывает указатель по смещению 0x18, оставляя X0 неизменным и устанавливая X1 в доступный для чтения буфер стека. Контролируемые байты пикселей рассматриваются как QmageStream: первые 23 байта содержат завершаемую нулём команду оболочки, а указатель по смещению 0x18 — __dl_popen. Это ограничивает команду первого этапа 23 символами, но удовлетворяет требованиям к обоим аргументам.

Получение обратной оболочки

В toybox для Android входит netcat, хотя и без -e. Команда из 23 байтов может получить неограниченный второй этап и передать его в sh:

Например:

Сервер на порту 1338 возвращает:

tail -f передаёт поступающие команды интерактивной оболочке, а временный файл служит каналом ввода. Атакующий получает второе соединение:

Оболочка работает от имени Samsung Messages и имеет доступ к базе данных SMS/MMS, фотографиям, контактам и другим разрешённым данным. Тот же декодер Qmage доступен в более привилегированных локальных процессах, например System UI, а размещённый файл .qmg потенциально может обеспечить закрепление в системе при последующем просмотре изображения.

Дальнейшая работа

Первопричина заключается в хрупком проприетарном кодеке Samsung, встроенном в Skia. Сообщалось о двух кампаниях фаззинга: находки января 2020 года были исправлены в мае как SVE-2020-16747/CVE-2020-8899, а майские — в июле как SVE-2020-17675. Продолжение независимого фаззинга остаётся полезным.

Цепочка также выявила слабые места в архитектуре Android и Samsung:

• Messages автоматически загружает и разбирает изображения MMS до подтверждения доставки и без песочницы для декодера изображений.

• Zygote сохраняет расположение адресного пространства после сбоев, позволяя накапливать однобитовые результаты.

• Доступная для чтения 2-гигабайтная теневая память CFI предоставляет опорную точку для слепого поиска.

• Библиотеки имеют низкую относительную энтропию вокруг этой точки, особенно linker64.

• XOM позволяет распознавать библиотеки по недоступным для чтения промежуткам кода.

• ActivityManager допускает неограниченные перезапуски, если сбои разделены 60 секундами работы.

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

• Android разрешает приложениям запускать программы командной строки и поставляется с сетевыми инструментами, полезными после эксплуатации.

В Android 11 распределителем памяти по умолчанию стал Scudo, XOM был отменён, поскольку нарушал работу PAN, теневая память CFI стала преимущественно недоступна для чтения, а между библиотеками появились более крупные случайные промежутки. Эти изменения существенно повышают стоимость воспроизведения цепочки, хотя дальнейшее усиление защиты по-прежнему необходимо.

Заключение

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

Современные средства защиты сделали эксплуатацию медленнее и менее надёжной, превратив атаку одним сообщением в цепочку продолжительностью 1–2,5 часа, но ни одно из них её не остановило. Отчёты о доставке MMS, проверка адресов bitmap, сохраняемые Zygote расположения, отпечатки библиотек и неограниченные перезапуски с интервалами вместе позволили обойти ASLR.

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

1. разобраться в расположении JSObject в памяти;

2. обойти рандомизацию StructureID и подделать JSArray;

3. использовать его butterfly для ограниченного доступа к памяти;

4. при желании обойти защиту Gigacage и PAC, получив быстрый примитив без ограничений.

Подделка объектов

Обычный объект JSC состоит из заголовка JSCell, указателя butterfly и, возможно, inline-свойств. В butterfly хранятся out-of-line-свойства, индексированные элементы, длина и ёмкость.

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

Большинство операций обращается к Structure. Исторически атакующие распыляли Structures, создавая множество объектов с уникальными свойствами, пока предсказуемый ID не становился допустимым для нужного типа. Рандомизация назначает идентификаторы с энтропией, нарушая такое простое предсказание.

Рандомизация StructureID

Возможные способы обхода включают утечку действительного ID, поиск кода, доверяющего только кешированным битам JSCell, или создание оракула для перебора семи случайных битов. JIT-проверка StructureCheck могла бы сообщать об успехе по времени bailout либо по различию результатов JIT и интерпретатора.

Интерпретатор предоставляет более простой путь. Его быстрый путь индексированной загрузки проверяет тип индексирования JSCell и длину butterfly, но никогда не читает StructureID:

canGetIndexQuickly использует предсказуемые биты индексирования и длину вектора butterfly. Поэтому частично поддельный объект может направить свой butterfly на настоящий массив double и прочитать заголовок JSCell этого массива, содержащий действительный рандомизированный StructureID.

Поддельный объект создаётся внутри inline-свойств контейнера. После замены его заголовка утекшим действительным заголовком он ведёт себя как корректный неупакованный double-массив JSArray. Изменение его butterfly перенаправляет загрузки и сохранения double на выбранные адреса.

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

Другие стратегии обхода StructureID описаны в документе eu-19-Wang-Bypassing-StructureID-Randomization.pdf (файл в files/eu-19-Wang-Bypassing-StructureID-Randomization.pdf).

Замечание о стабильности эксплойта

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

Замена поддельной JSCell утекшим действительным заголовком делает объект безопасным для GC. Остаётся более тонкая проблема: get_by_val кеширует последний наблюдавшийся StructureID для профилирования. Первая загрузка из недопустимого поддельного массива может загрязнить этот кеш, который позднее просканирует GC.

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

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

Выход из Gigacage

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

Указатели backing store TypedArray защищены двумя механизмами:

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

• PACCage: на поддерживаемых устройствах указатели backing store подписываются с помощью PAC, что препятствует простой модификации кучи.

Тем не менее перед каждым оптимизированным доступом DFG JIT должен превратить помещённый в cage и подписанный указатель в необработанный машинный адрес. Это временное значение вне cage и становится целью.

TypedArray в DFG

Для функции:

DFG создаёт примерно следующее:

GetIndexedPropertyStorage загружает указатель backing store, извлекает его из cage и аутентифицирует. Затем GetByVal выполняет обычный доступ к памяти. Если свободного регистра общего назначения нет, необработанный указатель выгружается в нативный стек. Атакующий, способный записать в этот слот стека между операциями, может заменить его произвольным адресом, обойдя обе защиты без подделки PAC.

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

Поиск стека

VM.topCallFrame указывает внутрь нативного стека, поскольку интерпретатор и JIT JSC используют нативные кадры вызовов. Начиная с глобального объекта, ограниченный примитив чтения кучи следует по указателям к внутреннему GlobalObject, затем к VM и topCallFrame:

После этого butterfly поддельного JSArray можно направить в стек и представить его слоты как элементы double.

Разделение операций доступа к TypedArray

При одиночном доступе GetByVal размещается сразу после извлечения указателя. Два обращения с разными индексами создают две операции извлечения:

CSE объединяет одинаковые операции GetIndexedPropertyStorage, но не может объединить GetByVal с разными индексами:

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

Выгрузка регистров

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

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

Полный PoC создаёт специализированную функцию из шаблона, дублируя отмеченные строки NUM_REGS + 1 раз. Он получает указатель стека через принудительно созданный нативный кадр вызова, ищет адрес backing store без PAC, поддерживает режимы чтения и записи, восстанавливает исходный указатель перед возвратом и многократно проверяет примитив на разных уровнях JIT и при GC.

После компиляции этот приём быстро и надёжно работает в macOS и iOS с различными сборками WebKit. Он предоставляет неограниченный доступ к памяти через обычный TypedArray, хотя находящийся в куче указатель остаётся в cage и подписан PAC.

Заключение

Рандомизация StructureID слаба, когда предсказуемые биты JSCell позволяют выполнять полезные операции интерпретатора без проверки ID, а чтение за границами кучи зачастую может напрямую раскрыть действительный идентификатор. Gigacage также имеет ограниченную ценность, пока неупакованные double-массивы JSArray вне cage предоставляют отдельный путь чтения и записи; после этого создаваемые JIT временные указатели позволяют обойти и Gigacage, и PACCage.

Удаление неупакованных массивов double и правильное помещение оставшегося хранилища JSArray в cage могло бы усилить обе защиты, предотвратив исходное смешение типов double/JSValue и ограничив утечки StructureID через чтение за границами.

Часть 3 превращает произвольное чтение и запись в управление PC, несмотря на APRR и PAC.

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

Область JIT имеет биты RWX в таблице страниц, но фактически доступна как RX. Когда компилятор обновляет код, один поток временно меняет индекс 7 на RW, выполняет копирование, а затем восстанавливает RX:

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

PAC

Pointer Authentication сохраняет криптографическую подпись в неиспользуемых битах указателя. Указатели кода аутентифицируются перед передачей управления, блокируя обычные ROP/JOP, когда атакующие не имеют доступа к ключам. performJITMemcpy всегда встраивается, поэтому удобного подписанного указателя функции, который можно вызвать с произвольными аргументами, нет.

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

Итоги

Вместе эти средства защиты обеспечивают:

• фактически RX-область JIT, временно доступную для записи только одному потоку копирования;

• обеспечиваемый PAC механизм CFI против классического повторного использования кода;

• проверку целостности между сборкой JIT-кода и его установкой.

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

Обход средств защиты JIT Эксплуатация без shellcode

Нативный shellcode требуется не всегда. Объектами среды выполнения Objective-C и JSC можно манипулировать, чтобы вызывать функции и системные вызовы из JavaScript, потенциально реализуя выход из песочницы напрямую. Структуры DFG, B3, AIR и вспомогательных компонентов компилятора также не защищены PAC; изменение IR могло бы заставить компилятор создавать контролируемые вызовы.

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

Состояния гонки

Многие границы APRR/PAC собирают несколько инструкций в доступной для записи памяти, а затем вызывают performJITMemcpy:

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

Незащищённые указатели кода

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

Большинство из них представляли собой безопасные константы:

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

JavaScriptCore создавал его для импортированных функций, на которые ссылались как на значения. Output::doublePow загружает функцию C pow, подписывает её и создаёт вызов. Замена доступного для записи указателя импорта обходит PAC:

После JIT-оптимизации процесс достигает PC 0x41414141.

Второй поиск обнаружил неподписанные косвенные вызовы __chkstk_darwin в начале функций с крупными кадрами стека:

Указатель снова находится в доступной для записи памяти без PAC. Его перезапись и запуск FTL-компиляции позволяют достичь выбранного адреса, когда FTL::lowerDFGToB3 создаёт свой большой кадр.

Эти варианты стали задачей Project Zero Issue 2044 и CVE-2020-9870, исправленной в iOS 13.6.

Манипуляции с сообщениями Mach

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

Хуки Frida на mach_msg с устранением дубликатов по стеку вызовов обнаружили IPC браузера, XPC и вызовы ядра. В каждом случае сообщение создавалось и отправлялось почти немедленно. Следовательно, для повреждения требовалась ещё одна небезопасная гонка, проигрыш которой портил сообщение в куче или стеке. Из соображений надёжности эти кандидаты были отклонены.

Злоупотребление обработчиками сигналов

Обычно PAC останавливает атаку, приводя к сбою процесса. Механизм исключений Mach в WebKit вместо этого может перехватывать ошибки, изменять состояние регистров и возобновлять выполнение. JSC использует это для проверок границ WebAssembly: 32-разрядный доступ в 32-гигабайтную защитную область вызывает ошибку, обработчик корректирует поведение, а JavaScript получает исключение.

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

1. В потоке renderer возникает ошибка.

2. Ядро пробуждает GCD-поток обработки исключений.

3. mach_msg_server_once получает сообщение об исключении и выделяет ответ.

4. Созданная MIG функция _Xmach_exception_raise_state_identity извлекает состояние сбойного потока.

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

6. MIG-заглушка кодирует результат и новое состояние в ответе.

7. Ядро либо возобновляет поток с этим состоянием, либо завершает его.

Эксплойт повреждает неподписанные указатели next списка обработчиков, превращая его в цикл. Ошибка в другом потоке заставляет GCD-worker бесконечно выполняться в catch_mach_exception_raise_state, фиксируя расположение его стека. Контролируемый атакующим поток сканирует непрерывно расположенные стеки потоков в поисках адреса возврата этой функции и находит выгруженный указатель на ответное сообщение.

Атакующий изменяет состояние регистров в ответе и результат успешного выполнения. PC остаётся защищён PAC, но регистры общего назначения и состояние стека можно контролировать. Выгруженный указатель перенаправляется, чтобы итоговый KERN_FAILURE настоящего обработчика был записан в другое место и не перезаписал поддельный ответ. После восстановления списка worker завершает работу; mach_msg_server_once отправляет контролируемое атакующим состояние, и ядро возобновляет сбойный поток.

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

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

• возникновение ошибки во время записи в область JIT и изменение регистра-источника;

• сохранение области JIT текущего потока доступной для записи путём возобновления в другом месте во время copyCompactAndLinkCode;

• многократный перехват ошибок аутентификации для перебора PAC и последующего достижения встроенного участка копирования JIT.

Опубликованный PoC использовал этот механизм для обхода PAC у TypedArray. Apple исправила варианты с обработчиком исключений как CVE-2020-9910 в iOS 13.6.

Сведения о Mach Interface Generator, использовавшемся заглушками исключений, сохранены в документации MIG.

Заключение

В исследовании рассматривались злоупотребление средой выполнения без shellcode, повреждение IR, гонки, необработанные указатели кода, гонки сообщений Mach и обработка исключений. Два ранее не публиковавшихся класса обеспечили надёжный обход защит: неподписанные доступные для записи импорты, подписываемые или вызываемые при использовании, и повреждение ответов на исключения Mach через остановленный поток обработчика. Apple исправила их как CVE-2020-9870 и CVE-2020-9910.

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

Логические ошибки могут и дальше обеспечивать выход из песочницы, однако компрометация renderer часто по-прежнему требует shellcode или эквивалентного нативного примитива. Многоуровневые средства защиты остаются полезными: MTE рядом с исходным повреждением, механизмы StructureID и cage на раннем этапе эксплуатации, PAC/APRR после получения чтения и записи, а вокруг них — более строгая изоляция процессов.

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

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

Что-то выглядит странно

При проверке драйвера KGSL от Qualcomm в апреле 2020 года было найдено исправление, рандомизировавшее GPU-адрес глобального scratch-буфера:

Виртуальные адреса GPU не являются обычными указателями ядра, поэтому применение ASLR к одному из них выглядело подозрительно. Исправление относилось к CVE-2019-10567. Сопутствующее изменение перенесло команды пользовательского профилирования в косвенный буфер, чтобы предоставленные пользователем адреса и значения больше не попадали непосредственно в ringbuffer.

Возникло два вопроса: почему данные атакующего в ringbuffer опасны и можно ли всё ещё раскрыть якобы рандомизированный scratch-адрес?

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

OpenGL ES и Vulkan скрывают от приложений аппаратные различия, но в конечном счёте взаимодействуют с драйвером ядра. На устройствах Qualcomm этим интерфейсом служит /dev/kgsl-3d0.

Через ueventd устройство глобально доступно для чтения и записи:

Его тип SELinux — gpu_device, с явным правилом для недоверенных приложений:

Поэтому процесс в песочнице может выделять память GPU, создавать контексты, отправлять потоки команд и отображать разделяемые страницы через ioctl KGSL и mmap.

Общие отображения GPU

IOCTL_KGSL_GPUMEM_ALLOC создаёт физические страницы и отображает их в контекст GPU через системный блок управления памятью (SMMU). Пользовательское пространство отображает те же страницы в адресное пространство CPU. Для одной и той же физической памяти CPU и GPU используют разные виртуальные адреса.

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

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

На устройстве с root-доступом их можно увидеть в debugfs:

Между перезагрузками перемещалось только 4-килобайтное scratch-отображение; остальные глобальные области оставались в диапазоне [0xfc000000, 0xfd400000]. Именно такую ограниченную рандомизацию ввели для CVE-2019-10567.

Scratch-буфер

Драйвер выделяет scratch во время инициализации:

В нём хранится общее состояние CPU/GPU. Важны два применения:

• туда записывается адрес буфера восстановления после вытеснения;

• GPU записывает туда указатель чтения (RPTR) каждого ringbuffer, который CPU читает при вычислении свободного места.

Второе применение связывает рандомизацию scratch с исправлением ringbuffer.

Основы ringbuffer

IOCTL_KGSL_GPU_COMMAND в конечном счёте отправляет работу через глобальный кольцевой буфер размером 32 КБ. CPU выступает производителем и продвигает WPTR, а GPU потребляет команды и продвигает RPTR. Драйвер определяет, помещается ли запрошенная последовательность команд:

adreno_get_rptr() читает значение из scratch. Ложный, искусственно завышенный RPTR заставляет распределитель вернуть пространство, перекрывающее команды, которые GPU ещё не обработал. CPU и GPU начинают по-разному оценивать занятую часть кольца, и новые команды перезаписывают ожидающие выполнения операции.

Атака на scratch RPTR

Пользовательское пространство не может напрямую отобразить scratch, однако предоставленные атакующим команды GPU могут записывать в него. У выделения отсутствуют как KGSL_MEMFLAGS_GPUREADONLY, так и KGSL_MEMDESC_PRIVILEGED.

Эти низкоуровневые операции не документированы, но их можно вывести из кода драйвера и экспериментов. CP_MEM_WRITE сохраняет константу, CP_WAIT_REG_MEM останавливается до выполнения условия, а CP_MEM_TO_MEM копирует данные между адресами GPU.

Рандомизированную страницу можно найти двумя способами. После исключения фиксированных глобальных отображений остаётся всего 2721 страница-кандидат; полный перебор занимал в среднем 7,5 минуты на телефоне среднего класса. Более быстрый способ использует настройку вытеснения: a6xx_preemption_pre_ibsubmit записывает указатель scratch в доступный для чтения ringbuffer как аргумент CP_MEM_WRITE. CP_MEM_TO_MEM копирует этот слот ringbuffer в контролируемую атакующим общую память, немедленно раскрывая scratch.

Перезапись ringbuffer

Adreno предоставляет четыре ringbuffer с разными приоритетами. Ringbuffer 0 не использовался обычными нагрузками Android на тестовом устройстве и создавал минимум шума. Сам ringbuffer доступен GPU только для чтения, поэтому пользовательские команды не могут изменить его напрямую; поддельный RPTR заставляет ядро перезаписать его от имени атакующего.

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

Защищённый режим

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

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

Это объясняет CVE-2019-10567. Гуан Гун использовал повреждение RPTR и аргументы профилирования, чтобы внедрить команды в ringbuffer в тщательно подобранном месте. Эти команды отключали защищённый режим, переходили к данным атакующего и изменяли TTBR0. Первоначальные исправления рандомизировали scratch и исключили значения профилирования из кольца.

Восстановление атаки

Раскрытие scratch обходит первое исправление. Вместо поиска другого интерфейса внедрения команд для обхода второго новый эксплойт меняет порядок законных операций ringbuffer.

Обычная привилегированная последовательность такова:

1. отключить защищённый режим;

2. выполнить переключение контекста или другую привилегированную операцию;

3. снова включить защищённый режим.

Атакующий вступает в гонку между этапами 1 и 3. Пока GPU выполняет законную последовательность с отключённой защитой, повреждение RPTR заставляет CPU перезаписать команды переключения контекста законным косвенным переходом, контролируемым атакующим.

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

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

Proof of concept размещает эти таблицы на известной физической странице путём распыления buddy allocator; ION мог бы повысить надёжность. Поддельная трансляция затем отображает произвольную физическую память. Поскольку ядра Android занимают предсказуемые физические адреса, команды GPU могут перезаписать код или данные ядра и добиться выполнения в ядре.

Итоговая атака

Proof of concept Adrenaline нацелен на Pixel 3a со сборкой sargo-user QQ2A.200501.001.B3 и ядром 4.9.200-gdf3ca60d978c-ab6351706. Для демонстрации управления PC он перезаписывает запись sys_call_table.

Помимо гонки с вероятностью 20% остаются два ограничения. Смещения ringbuffer различаются между версиями ядра, хотя стабильны для каждой сборки и могут вычисляться автоматически. Распыление фиксированной страницы через buddy allocator в демонстрации может столкнуться с уже занятой памятью; более управляемый распределитель должен устранить эту неопределённость.

Хронология исправления

CVE-2020-11179 была исправлена ограничениями прошивки GPU и драйвера ядра, защищающими scratch от пользовательских команд, выполняющихся через косвенные переходы.

Рекомендации Прозрачность и открытость

GPU выполняет сложную обработку недоверенных входных данных, одновременно обеспечивая критически важную границу изоляции Android. Adreno и Mali должны предоставлять проектную документацию, по возможности исходный код и явные модели угроз и безопасности. Когда-то закрытость аппаратного обеспечения могла давать конкурентное преимущество, но теперь от этих компонентов зависит безопасность ОС для миллиардов пользователей.

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

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

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

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

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

Заключение

CVE-2020-11179 — необычайно мощная проблема Adreno. Доступное для записи глобальное scratch-отображение позволяет командам GPU атакующего подделать указатель чтения ringbuffer. Возникающая рассинхронизация CPU/GPU создаёт повторяемую гонку, подменяющую косвенный переход при отключённом защищённом режиме. Этот переход изменяет TTBR0, отображает произвольную физическую память и выходит из песочницы Android-приложения с выполнением кода в ядре.

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

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

Например, администратор сопоставляет роль исполнения AWS Lambda с ролью Vault:

Lambda отправляет подтверждение своего идентификатора AWS в /v1/auth/aws/login. Vault возвращает краткосрочный токен для dbclient, с помощью которого можно получить пароль базы данных, сертификат или динамически созданные учётные данные. Функция не содержит статического секрета Vault, а каждое получение централизованно регистрируется для аудита.

За этой простотой скрывается сложная граница доверия: неаутентифицированный клиент предоставляет сериализованный облачный запрос, который Vault пересылает и интерпретирует.

sts:GetCallerIdentity

Рекомендуемый метод AWS iam основан на STS GetCallerIdentity. Клиенты AWS аутентифицируют запросы API с помощью HMAC-подписи канонического запроса. Клиент может заранее подписать один запрос и передать его другой стороне, не раскрывая секретный ключ.

Vault принимает закодированные в base64 HTTP-метод, URL, тело и заголовки, после чего пересылает предварительно подписанный запрос в STS:

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

Это блокирует прямой SSRF к серверу атакующего, но оставляет большую неаутентифицированную поверхность, частично определяемую поведением STS.

Кража идентификатора вызывающего STS

Уловки разбора URL и маршрутизация по заголовку Host не позволили перенаправить запрос. Управление строкой запроса полезнее: Vault никак не ограничивает Action STS, поэтому клиент может вызывать любой API STS, а не только GetCallerIdentity.

Каждый ответ HTTP 200 разбирается как XML:

Vault не проверяет Content-Type ответа. STS возвращает JSON, если запрос содержит Accept: application/json. XML-декодер Go игнорирует не-XML-текст до и после ожидаемого корневого элемента, поэтому JSON-строка со встроенным <GetCallerIdentityResponse>...</GetCallerIdentityResponse> принимается.

Остаётся найти действие STS, отражающее контролируемую атакующим пунктуацию. AssumeRoleWithWebIdentity возвращает subject JWT как SubjectFromWebIdentityToken. Атакующий может создать поставщика OIDC в посторонней учётной записи AWS, зарегистрировать его для контролируемой роли и подписывать произвольные subject JWT.

Вредоносный токен содержит поддельный ответ:

Предварительно подписанный запрос STS выбирает JSON:

STS отражает subject внутри корректного JSON:

XML-парсер Vault пропускает окружающий JSON, извлекает встроенные ARN/UserId и принимает их за идентификатор вызывающего STS. Атакующий сериализует запрос в ожидаемой Vault форме и входит в систему:

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

Недостаток шире одной особенности парсера. Защитный продукт пересылает неаутентифицированный, почти полностью контролируемый атакующим HTTP-запрос через внешний API, маршрутизация и поведение ответов которого могут независимо измениться. HashiCorp исправила проблему с помощью списка разрешённых заголовков, ограничения действия до GetCallerIdentity и более строгой проверки ответа STS.

Эксплуатация Vault в GCP

Метод аутентификации GCP в Vault поддерживает:

• iam — для произвольных служебных учётных записей и сервисов, например App Engine или Cloud Functions;

• gce — для виртуальных машин Compute Engine и политик на основе проекта, зоны, группы экземпляров, меток и других метаданных VM.

Оба используют JWT. Клиент IAM подписывает его напрямую ключом служебной учётной записи или через projects.serviceAccounts.signJwt. Виртуальная машина GCE запрашивает токен идентификации у своего metadata server. Токены GCE подписываются общим сертификатом Google и содержат доверенное поле compute_engine:

Vault обрабатывает оба класса токенов в parseAndValidateJwt. Он разбирает непроверенный заголовок, читает kid и сначала пытается получить общий открытый ключ OAuth от Google:

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

Затем Vault проверяет JWT и копирует пользовательские поля Compute Engine в состояние входа:

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

Атакующий создаёт служебную учётную запись в собственном проекте, подписывает JWT с поддельными метаданными существующей привилегированной целевой VM и отправляет его роли gce:

Vault проверяет два внешних факта. Описанная VM должна существовать; достаточно совпадения идентификатора проекта, зоны и имени экземпляра. Служебная учётная запись атакующего также должна существовать, а идентификатор GCP, используемый Vault, должен иметь для неё разрешение iam.serviceAccounts.get, которое атакующий может предоставить в собственном проекте даже субъекту allUsers.

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

Первопричина — объединение двух типов токенов с принципиально разными свойствами доверия в одном пути проверки. Поля compute JWT от metadata server контролируются Google, а пользовательские поля обычного JWT служебной учётной записи — её владельцем. Корректная подпись сама по себе не делает каждое поле авторитетным.

Заключение

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

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

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

Краткое введение для тех, кто меньше знаком с ядрами Apple: ядро Apple называется XNU, а IOKit — это C++-фреймворк XNU для реализации драйверов. Приложение в пользовательском пространстве может вызвать IOServiceGetMatchingServices() и получить дескрипторы драйверов, но с исходным дескриптором драйвера почти ничего нельзя сделать. Вместо этого приложение должно поручить драйверу создать «пользовательский клиент», вызвав IOServiceOpen() и передав нужный тип клиента. Поскольку именно пользовательский клиент предоставляет основную часть функций пользовательскому пространству, на этом этапе выполняется проверка песочницы, подтверждающая право приложения открыть запрошенный тип. Получив дескриптор пользовательского клиента драйвера, приложение может взаимодействовать с ним, вызывая функции вроде IOConnectCallMethod() и указывая «селектор» (индекс) нужного метода. В ядре IOConnectCallMethod() использует селектор для индексирования таблицы методов пользовательского клиента и вызывает запрошенный метод.

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

В процессе реверса я обнаружил несколько любопытных вещей. Во-первых, у H11ANEIn, по-видимому, было два пользовательских клиента: H11ANEInDirectPathClient, который я открыл, и H11ANEInUserClient, недоступный мне в песочнице. Судя по строкам в методе H11ANEIn::newUserClient(), H11ANEInDirectPathClient представлял собой менее привилегированную версию H11ANEInUserClient, поэтому логично, что первый я мог открыть, а второй — нет.

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

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

Это было видно по тому, как методы ::externalMethod() каждого клиента обращались к перекрывающимся частям таблиц. Версия H11ANEInDirectPathClient:

И версия H11ANEInUserClient:

Каждый мог обращаться к 34 методам, а первые три элемента массива были зарезервированы для H11ANEInDirectPathClient. Следовательно, последние три должны были предназначаться для H11ANEInUserClient, что, похоже, подтверждалось общим количеством в 37 методов. Забавно.

Я начал разбираться с методами, доступными H11ANEInDirectPathClient, и очень быстро пришёл к выводу, что качество кода этого драйвера невысоко. Например, в методе H11ANEIn::ANE_ProgramSendRequest_gated() длиной 3500 строк, доступном через селекторы 2 и 33, прямо в начале функции обнаружилось несколько тривиальных чтений за границами:

Здесь содержимое args полностью контролируется, поэтому счётчик args->totInputBuffers может быть сколь угодно велик и выходить за границы массивов inputBufferSymbolIndex и inputBufferSurfaceId.

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

Через секунду после запуска приложения-фаззера устройство упало с kernel panic.

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

Ещё раз, теперь с символами

Перенесёмся в конец августа.

Как ранее случилось с бета-версией iOS 12, Apple случайно включила kernelcache с символами в несколько бета-выпусков iOS 14. Я ещё не успел их исследовать, но решил, что появление символов, и особенно ограниченной информации о типах, которую можно вывести из декорированных имён методов C++, ускорит реверс сети многотысячестрочных функций H11ANEIn и сделает его более оправданным. Поэтому я открыл IDA и снова перешёл к таблицам внешних методов в поисках очевидных изменений.

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

Как ни странно, таблицы внешних методов и H11ANEInDirectPathClient, и H11ANEInUserClient имели определённые символы. Это было странно: я ожидал, что код состоит из одного массива структур IOExternalMethodDispatch, где H11ANEInDirectPathClient может использовать 34 метода начиная с индекса 0, а H11ANEInUserClient — 34 метода начиная с индекса 3. В таком расположении должен был быть только один символ для всего массива.

Тут меня осенило: моя идея перекрывающихся массивов внешних методов была полной бессмыслицей, а «совместное использование» внешних методов представляло собой обычный доступ за границы со стороны H11ANEInDirectPathClient! У менее привилегированного клиента должно было быть всего три метода, но из-за опечатки в проверке границ H11ANEInDirectPathClient мог обращаться к внешним методам более привилегированного клиента и вызывать их. При этом H11ANEInDirectPathClient при каждом вызове метода H11ANEInUserClient неявно приводил к смешению типов указателя this!

Оглядываясь назад, я понял, что схема с «совместным использованием массивов внешних методов» не имела смысла: при таком подходе требовалось бы тщательно избегать смешения типов между двумя классами пользовательских клиентов, но никаких мер предосторожности не принималось. Уверенность окончательно укрепилась, когда я декомпилировал H11ANEInDirectPathClient::externalMethod() в новом kernelcache и увидел, что верхняя граница селектора уменьшилась с 33 до 2: ошибка была исправлена.

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

Ещё один рецепт копипаста

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

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

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

Заключение

Итак, какие выводы можно сделать из этой истории?

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

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

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

В твите от мая 2020 года упоминалось доступное через AWDL двойное освобождение в BSS steering. При аудите соседнего кода выделился небезопасный вызов memmove в IO80211AWDLPeer::parseAwdlSyncTreeTLV.

SyncTree TLV объявляет переменное количество MAC-адресов одноранговых узлов. Назначением служит массив фиксированного размера внутри IO80211AWDLPeer; недостаточная проверка позволяет удалённому кадру копировать данные за его пределы. Переполняющие байты контролируются не полностью, но в основном состоят из выбранных атакующим MAC-адресов и управляемых данных обрамления.

Первый proof of concept

Первоначальный воспроизводящий пример создавал некорректный action frame AWDL с чрезмерно большим SyncTree TLV и передавал его через Wi-Fi-адаптер в режиме мониторинга. Любое находившееся рядом уязвимое устройство с активным AWDL разбирало кадр в ядре и падало.

Атака не требует аутентификации. Не нужно подключаться к Wi-Fi-сети жертвы, знать пароль, выполнять сопряжение или устанавливать обычное IP-соединение. Однако на этом этапе AWDL зачастую должен был уже быть активен, например при открытой панели общего доступа.

Что такое AWDL?

AWDL — проприетарный одноранговый Wi-Fi-протокол Apple, используемый AirDrop, Sidecar и связанными функциями. Обычные Wi-Fi-клиенты передают данные через точку доступа, даже находясь физически рядом.

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

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

Кадры AWDL

Пакет AWDL представляет собой action frame IEEE 802.11. Он содержит заголовок 802.11, заголовок action frame, фиксированный заголовок AWDL, а затем содержимое в кодировке TLV.

Важные TLV объявляют синхронизацию, последовательности каналов, сервисы, состояние узла, метрики выбора и BSS steering. Драйвер ядра получает необработанные кадры, проверяет фиксированные поля, находит или создаёт IO80211AWDLPeer и передаёт TLV методам разбора C++.

Уязвимость SyncTree в контексте

IO80211AWDLPeer принадлежит зоне выделения IOKit. Линейная перезапись может затронуть:

• поля в конце текущего peer;

• начало соседнего peer;

• другой объект в той же зоне;

• в зависимости от расположения распределителя — объект в другой зоне.

Современные устройства A12/A13 добавляют PAC к vtable C++ и указателям кода, поэтому простая замена vtable больше не даёт управления PC. Вначале эксплуатация должна повреждать неподписанные указатели данных и состояние, сохраняя аутентифицированный поток управления.

Выход в эфир

Для создания клиента AWDL использовались режим мониторинга Linux и внедрение пакетов. Заголовки Radiotap перед необработанным кадром 802.11 несут метаданные передачи, например канал, скорость, антенну и флаги.

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

Первая половина MAC-адреса — его OUI. Биты первого байта отличают multicast от unicast и локально администрируемые адреса от глобально уникальных.

ACK от цели подтверждает, что поддельный кадр достиг Wi-Fi-чипсета и был принят на уровне 802.11.

Проблема A12/A13

Виртуальные вызовы ARM64e аутентифицируют подписанный указатель vtable и, в зависимости от места вызова, подписанный указатель функции с помощью ключей и дискриминаторов.

Heap grooming позволяет выделить множество объектов peer путём подделки исходных MAC-адресов. Затем переполнение достигает выбранных неподписанных полей peer: ссылок списка, MAC-адреса, указателя manager, счётчиков и состояния протокола.

Каждый OSObject начинается с vtable и счётчика ссылок. Далее IO80211AWDLPeer содержит hash bucket, указатели двусвязного списка peer, MAC-адрес и указатель peer-manager.

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

Безопасные объекты и ответы сервисов

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

Объекты Service Response Descriptor (SRD) предоставили более мощный примитив кучи. Специальные кадры ответов сервисов AWDL выделяют контролируемые объекты в предсказуемых зонах. Страницы можно заполнить этими безопасными объектами, а затем создать отверстия для peer.

Окружение целевого peer безвредными освобождаемыми объектами гарантирует, что неточное переполнение либо достигнет нужного peer, либо повредит данные, которые не будут разыменованы.

Перезапуск и обновлённые структуры

После нескольких тупиков расположение объекта было подробнее восстановлено в IDA. Определение локальных C-подобных типов сделало использование полей и переходы состояния в декомпилированном коде понятными.

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

BSS steering и построение чтения

Тщательно выстроенная последовательность кадров AWDL переводит peer между состояниями BSS steering и даёт почти произвольное чтение ядра. Изначально примитив ограничен по длине, времени и целевому адресу, но способен возвращать память в беспроводных ответных кадрах.

Первая задача — найти подготовленные атакующим объекты. Zone-map ASLR имеет меньшую энтропию слайда, чем полный размер карты, поэтому по крайней мере один виртуальный адрес гарантированно попадает внутрь zone map при каждой загрузке.

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

Удалённое сканирование в конце концов возвращает два соседних peer. Их заголовки раскрывают подписанные PAC vtable, ссылки списка, MAC-адреса, указатели manager и временные метки.

Зная точные адреса, можно через переполнение SyncTree изменить нижние поля верхнего peer, не затрагивая его аутентифицированную vtable.

От чтения к записи

Повреждение upper_peer->peer_manager создаёт косвенный примитив сложения. При учёте поддельного кадра actionFrameReport прибавляет длину кадра к 32-разрядному счётчику общего количества принятых байтов по смещению +0x7c80 от указателя manager.

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

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

Запуск Calculator с помощью 15 байтов

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

Повышение надёжности радиосвязи

Steering множества peer заполняет канал сообщениями Unsolicited Measurement Indications, непропорционально направленными первому peer.

Для надёжной эксплуатации потребовались учитывающая ACK регулировка темпа, повторы, выбор канала и в итоге поддержка 5 ГГц. Множество USB Wi-Fi-адаптеров было проверено на режим мониторинга, внедрение пакетов и active monitor.

При активированном вручную AWDL цепочка за несколько секунд получала чтение и запись ядра и запускала Calculator.

Ноль щелчков: удалённое включение AWDL

Последним взаимодействием пользователя оставалось открытие функции, включавшей AWDL. Обнаружение соседних устройств начинается через Bluetooth Low Energy. Тщательно подготовленные объявления BLE могут заставить iOS поверить, что peer предоставляет сервис на базе AWDL, и активировать интерфейс Wi-Fi.

BBC micro:bit стал недорогим программируемым передатчиком объявлений BLE.

Часть аутентификации объявления требовала перебора двух байтов данных, полученных из SHA-256, что достаточно мало для решения в реальном времени. Атакующий передаёт объявление, ждёт активации AWDL, а затем без щелчка, уведомления или видимого запроса начинает Wi-Fi-эксплойт.

Полная zero-click-демонстрация запуска Calculator занимает около минуты с неактивного домашнего экрана.

От доступа к ядру до импланта

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

Исходный примитив сложения был оптимизирован в более быструю запись. Рассматривались произвольные физические отображения: исторически physmap отображает всю физическую память в виртуальное пространство ядра, однако новые устройства ограничивают это через APRR, PPL и pmap_cs. Обход использует разрешённые операции pmap и тщательно подобранные отображения вместо непосредственного изменения защищённых таблиц страниц.

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

Стадия 0

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

Стадия 1

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

Минимальный имплант

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

В финальной демонстрации атакуется iPhone 11 Pro в другой комнате за закрытой дверью, пока жертва смотрит YouTube. BLE незаметно включает AWDL, Wi-Fi-цепочка получает доступ к ядру, и примерно за две минуты доставляется root-имплант. Дополнительная инженерная работа могла бы сократить время до нескольких секунд.

Заключение

Эксплойт начался с одного неограниченного копирования в ядре в недокументированном proximity-протоколе. Для получения стабильного zero-click-импланта потребовалось намного больше исходной ошибки: радиооборудование, реверс AWDL, heap grooming, безопасное для PAC повреждение данных, злоупотребление конечным автоматом BSS, удалённые примитивы чтения и сложения, синхронизация, обработка ACK, учитывающие PPL манипуляции ядром и поэтапная доставка полезной нагрузки.

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

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

Открытие устройства создаёт npu_session. Graph ioctl достигает npu_session_s_graph() и __config_session_info(), которая в два прохода разбирает общий буфер ION:

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

Переполнение кучи

Если установить memory_vector_cnt в 1 для предварительного прохода, будет выделен массив из одного элемента, после чего поток пользовательского пространства в ходе гонки изменит значение на 100 перед вторым проходом. Если все элементы имеют тип MEMORY_TYPE_IN_FMAP, ядро запишет 100 контролируемых атакующим записей temp_av в одноэлементное выделение.

Это мощный примитив: размер выделения, длина переполнения и большинство байтов контролируются. Простой поток, чередующий значения 1 и 100, выигрывает примерно в 25% попыток, поскольку два чтения ядра должны увидеть разные значения в нужном порядке.

Сложение за границами

Вторая детерминированная ошибка обрабатывает элемент MEMORY_TYPE_WEIGHT. address_vector_offset и address_vector_index читаются без проверки границ и выравнивания:

Если исходное 32-разрядное значение не превышает размер ION-буфера, драйвер прибавляет адрес буфера на устройстве NPU и записывает результат обратно:

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

Мышление примитивами iOS

В iOS контролируемое переполнение кучи напоминает CVE-2017-2370: оно могло бы повредить out-of-line-массив портов Mach, внедрить поддельный task port, получить чтение pid_for_task, а затем превратить поддельный объект в kernel task port. Сложение NPU напоминает oob_timestamp, где небольшая запись увеличивает ipc_kmsg и перекрывает следующий массив портов.

В Android нет портов Mach и канонического конечного состояния tfp0. Вместо изучения целого каталога целевых объектов Linux эксплойт сосредоточен на стеках ядра, находящихся в той же области vmalloc, что и отображения ION. В стеке много временных размеров и указателей, последующее использование которых может превратить ограниченное сложение в общее повреждение памяти.

Выбор пути

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

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

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

На устройстве для разработки /proc/vmallocinfo раскрывает диапазоны области vmalloc, размеры и места выделения. Стек потока ядра содержит четыре страницы данных и одну защитную страницу, занимая 0x5000 байт.

Heap grooming выполняется путём выделения большой области vmalloc, распыления стеков для заполнения меньших отверстий, освобождения большой области, отображения ION-буфера в новое отверстие, а затем создания целевого потока, стек которого попадает сразу после буфера. Отображения Binder и дополнительные выделения ION предоставляют крупные управляемые резервации и отверстия vmalloc.

Целевая смежность достаточно стабильна, чтобы сложение за границами достигало выбранного смещения стека. Первоначально планировалось использовать отображение на базе FUSE для блокировки copy_to_user или copy_from_user при page fault, но политика SELinux устройства предшествовала появлению разрешения на mmap файлов app-fuse.

Новый подход к чтению с pselect

pselect() детерминированно блокируется перед копированием результирующих битовых карт из локального буфера стека. core_sys_select() использует 256-байтовое выделение stack_fds при малом количестве дескрипторов:

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

Эта утечка раскрывает stack canary, адреса возврата, сохранённые регистры, адреса образа ядра и виртуальный адрес ядра для общих данных ION, необходимый последующей ROP.

Новый подход к записи

Первоначальный план был направлен на сохранённый SPSR в конце стека ядра. Изменение уровня исключения с EL0 на EL1 и установка сохранённых PC и регистров могли бы возобновить системный вызов как код ядра. В Galaxy S10 отсутствует защита SPSR с помощью PAC, но ARM64_UNMAP_KERNEL_AT_EL0 удаляет отображение ядра во время возврата из исключения. Попытка перехода вызывала ошибку в неожиданном состоянии и зависание watchdog вместо полезного kernel panic, поэтому этот путь был оставлен.

Итоговая запись также злоупотребляет pselect, но во время самого do_select. После увеличения n цикл читает и записывает fd-битмапы за пределами stack_fds:

Выходные данные перемещаются вниз через сохранённое состояние и адреса возврата.

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

stack_fds находится за 0x348 байт до конца стека. Более дальнее продвижение вызывает panic на неотображённой памяти. При исходном n = 0x140 каждая из шести fd-битмап занимает 0x28 байт. Безопасное повреждённое n должно быть намного больше, но оставаться ниже примерно 0x1400.

Ни один доступный daddr ION, прибавленный с одного байтового смещения, не даёт подходящего малого значения. Два ION-буфера обеспечивают достаточно степеней свободы: тщательно выбранные адреса, прибавленные по соседним невыровненным смещениям, превращают 0x140 в 0x1140. Тот же процесс подготовки и раскрытия vmalloc выбирает и проверяет оба отображения.

Управление содержимым

Выходные биты контролируются выбором файловых дескрипторов и их готовностью к чтению. Когда входной указатель inp продвигается на 3 * n = 0x3c0 бит, он начинает читать ранее записанный результат res_in. Каждый последующий бит равен единице, только если его предшественник один цикл назад был выбран, а соответствующий FD доступен для чтения.

Если весь 64-разрядный результат равен нулю, do_select не сохраняет его, оставляя прежнее слово стека. Поскольку байтовый цикл равен 3 * 0x28 = 0x78, примитив можно консервативно рассматривать как запись до 15 различных 64-разрядных значений в выбранные остатки по модулю 0x78 с сохранением остальных слов.

Два значения настраивают повреждённое n; остальные контролируемые слова образуют компактную ROP-цепочку. Файловые дескрипторы с известной готовностью кодируют необходимые единицы и нули.

Итоговая ROP

Янн Хорн предложил ___bpf_prog_run, интерпретатор eBPF, в качестве окончательного ROP-гаджета. Хотя он предназначен для исполнения байткода, уже одобренного верификатором, прямой вызов с байтами атакующего предоставляет:

• произвольный поток управления внутри байткода;

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

• вызовы функций ядра с числом аргументов до пяти и 64-разрядным результатом.

Обёртка имеет удобную сигнатуру:

Только X1 должен указывать на контролируемые инструкции. core_sys_select восстанавливает X20 из контролируемого слота переполнения. Небольшой гаджет эпилога перемещает X20 в X1 и возвращается:

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

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

Заключение

Качество аппаратных защит Galaxy S10 оказалось выше ожидаемого. В его Snapdragon 855 отсутствуют более новые функции ARMv8.3-A и специфичные для Apple KTRR/APRR/PPL, однако Android использовал надёжное поведение usercopy и UNMAP_KERNEL_AT_EL0. Собственные средства защиты Apple сами по себе не помешали бы этому эксплойту получить чтение и запись ядра.

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

Тем не менее межплатформенный мысленный эксперимент оказался полезным. Оба ядра предоставляют общие отображения, страничные виртуальные распределители, временное состояние стека и мощные интерпретаторы или объектные системы. Необычный путь итогового эксплойта — смежность ION, заблокированный pselect, циклическое переполнение fd-битмапа и прямой вход в интерпретатор eBPF — появился благодаря переносу знакомых целей, а не копированию знакомого механизма.

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

В публикации описывается этап после эксплуатации цепочки. Различные части цепочки я буду называть «стадией X». Номера стадий означают:

• Стадия 1: эксплойт renderer Chrome

• Стадия 2: эксплойт повышения привилегий Android

• Стадия 3: загрузчик после эксплуатации ← описывается в этой публикации!

• Стадия 4: имплант

Здесь подробно рассматривается стадия 3 — код, выполняемый после эксплуатации. Стадия 3 представляет собой ARM ELF, который рассчитывает на запуск от root. Этот ELF встроен в секцию данных двоичного файла стадии 2. Стадия 3 служит загрузчиком стадии 4.

Как уже отмечалось, стадия 3 — очень качественно спроектированное программное обеспечение. Оно тщательно скрывает своё поведение и проверяет, что работает на правильно выбранном целевом устройстве. Стадия 3 включает обфускацию, множество проверок против анализа, подробное журналирование, связь с сервером управления (C2) и в конечном счёте загрузку и исполнение стадии 4. Судя по размеру и модульности кода, его, вероятно, разрабатывала команда, а не один человек.

Перейдём к самому интересному!

Выполнение

После успешного получения root-доступа и изменения различных настроек безопасности стадия 2 загружает стадию 3. Стадия 3 встроена в секцию данных стадии 2 и имеет размер 0x436C байт. В стадии 2 реализовано несколько способов загрузки ELF стадии 3, в том числе запись в /proc/self/mem. Как только один из методов срабатывает, выполнение передаётся стадии 3.

ELF стадии 3 экспортирует две функции: init и d. Стадия 2 вызывает init, чтобы начать выполнение стадии 3. Однако основная функциональность двоичного файла находится не в этой функции, а в двух функциях, на которые ссылается .init_array ELF. Первая проверяет, что переменные окружения PATH, ANDROID_DATA и ANDROID_ROOT имеют ожидаемые значения. Вторая создаёт новый поток, выполняющий основную работу двоичного файла. Функция init лишь вызывает pthread_join для потока, созданного второй функцией из .init_array, и ждёт его завершения.

Новый поток сначала убирает следы предыдущей стадии, удаляя большинство переменных окружения, заданных стадией 2. Затем он завершает все процессы, в командной строке которых есть слово "knox". Knox — платформа безопасности, встроенная в устройства Samsung.

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

Затем двоичный файл перебирает открытые файловые дескрипторы процесса 0–2, обычно stdin, stdout и stderr, и перенаправляет их в /dev/null. Это предотвращает появление сообщений, по которым пользователь или кто-то ещё мог бы обнаружить цепочку эксплуатации. После этого код перебирает остальные открытые дескрипторы процесса в /proc/self/fd/ и закрывает те, чьи символические ссылки содержат "pipe:" или "anon_inode:". Он также закрывает дескрипторы с номером больше 32, если ссылка содержит "socket:", и все дескрипторы, имена которых не содержат /data/dalvik-cache/arm или /dev/. Возможно, это препятствует отладке или уменьшает риск случайно повредить остальную систему.

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

В остальной публикации технические детали поведения двоичного файла стадии 3 сгруппированы по категориям.

Обфускация

Стадия 3 скрывает своё поведение несколькими уровнями обфускации. Она использует метод обфускации строк, похожий на стадию 2. Кроме того, двоичный файл хранит динамические настройки и состояние в хеш-таблице. Вместо понятной строки в качестве «ключа» в хеш-функцию передаётся последовательность из 16 байтов, расшифрованных AES. Двоичный файл шифрует AES статическую конфигурацию, связь с C2 и хеш-таблицу с динамическими настройками. Сохраняемый на устройстве файл state.parcel закодирован XOR. Также в двоичном файле есть несколько методов, усложняющих понимание поведения посредством динамического анализа. Например, он отслеживает отображения в память процесса и открытые файловые дескрипторы и отправляет C2-серверу очень подробную информацию.

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

Обфускация строк

Подавляющее большинство строк внутри двоичного файла обфусцировано. Метод очень похож на применявшийся в предыдущих стадиях. Перед использованием обфусцированная строка передаётся функции деобфускации. Такие строки отмечены 0x7E7E7E ("~~~") в конце. Для их деобфускации мы использовали IDAPython-скрипт на базе flare_emu, эмулировавший функцию деобфускации для каждой строки.

Расшифровка настроек конфигурации

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

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

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

Шифрование хеш-таблицы

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

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

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

Для взаимодействия с хеш-таблицей во всём двоичном файле используются две основные функции, которые мы назовём getValueFromHashtable и putValueInHashtable. Обе принимают четыре аргумента: указатель на manager хеш-таблицы, указатель на ключ, обычно представленный как смещение от начала расшифрованного блока ключей, указатель на значение и целое число длины значения. Далее я буду ссылаться на значения хеш-таблицы. Поскольку ключ представляет собой последовательность из 0x10 байт, я буду говорить «значение по смещению 0x20 в хеш-таблице». Это означает значение, хранящееся для «ключа» длиной 0x10 байт, который начинается по адресу начала расшифрованного блока ключей + 0x20.

Каждая запись хеш-таблицы имеет следующую структуру.

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

Хеш-таблица периодически записывается в файл uierrors.txt, как описано в разделе о persistence. Это сохраняет состояние на случай завершения процесса.

Persistence

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

Файл state.parcel

При запуске код записывает текущее время в файл state.parcel. После записи времени в начало файла он читает все уже сохранённые времена и проверяет, сколько раз в день это выполнялось. Если за текущий день записей меньше шести, код продолжает работу. Если за текущий день есть шесть записей и не менее пяти записей за каждый из трёх предыдущих дней, двоичный файл устанавливает переменную, предписывающую очиститься и завершить работу. Если за текущий день есть шесть записей и хотя бы одна запись за каждый из трёх последних дней, двоичный файл удаляет постоянные файлы этой и других стадий, а затем выполняет максимальный сон: sleep(0xFFFFFFFF), что эквивалентно ожиданию более 136 лет.

Если эффективный UID равен 0 (root), код случайно выбирает для записи файла один из следующих путей:

• /data/backup/

• /data/data/

• /data/

• /data/local/

• /data/local/tmp/

Если эффективный UID не равен 0, файл state.parcel записывается в каталог, из которого выполняется двоичный файл согласно /proc/self/exe. Содержимое state.parcel обфусцируется путём XOR каждой записи с 0xFF12EE34.

uierrors.txt — содержимое хеш-таблицы

Стадия 3 периодически записывает хеш-таблицу с конфигурацией и статической информацией в файл uierrors.txt. Для выбора каталога используется тот же процесс, что и для state.parcel.

При каждой записи хеш-таблицы в uierrors.txt она шифруется AES256. Используется тот же ключ AES, что для расшифровки блока настроек конфигурации, но для IV создаётся набор из 0x10 случайных байт. Сначала IV записывается в файл uierrors.txt, затем зашифрованное содержимое хеш-таблицы. CRC32 зашифрованного содержимого записывается последними четырьмя байтами файла.

Переменные окружения

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

Обработка ошибок и журналирование

В двоичном файле реализован очень подробный и зрелый механизм журналирования. Он отслеживает как сообщения об «ошибках», так и «информационные» сообщения. Они сохраняются до отправки C2-серверу при автоматическом обращении стадии 3 либо «по требованию» вызовом подпрограммы, адрес которой хранится в переменной окружения "def". Подпрограмма из переменной "def2" добавляет сообщения в очереди ошибок и/или информационных сообщений. По всему двоичному файлу разбросаны сотни разных сообщений журнала. Значения некоторых кодов документированы здесь.

Очистка

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

• Подключается к сокету /dev/socket/logd и очищает все журналы.

• Выполняет klogctl(5,0,0), то есть SYSLOG_ACTION_CLEAR, очищая кольцевой буфер.

• Удаляет все файлы в следующих каталогах:

• /data/tombstones

• /data/misc/audit

• /data/system/dropbox

• /data/anr

• /data/log

• Удаляет файл /cache/recovery/last_avc_msg_recovery.

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

Связь с C2-сервером

Главная задача двоичного файла — загрузить следующую стадию с сервера управления (C2). После завершения предшествующей распаковки и проверок двоичный файл начинает готовить сетевое взаимодействие. Сначала он выполняет DNS-тест, затем собирает сведения об устройстве и отправляет POST-запрос C2-серверу. Если все этапы успешны, в ответ приходит следующая стадия, которую код готовит к исполнению.

DNS-тест

Перед обращением к C2-серверу двоичный файл выполняет DNS-тест. Функция получает указатель на расшифрованный блок данных. Сначала она создаёт случайное имя хоста длиной от 8 до 16 строчных латинских букв, а затем вызывает для него getaddrinfo. Она пытается найти хост, для которого getaddrinfo вернёт EAI_NODATA, то есть отсутствие сведений об адресе. Если ни один из трёх адресов не вернёт EAI_NODATA, функция прекращает попытки. Некоторые отключённые от сети аналитические песочницы отвечают на любые имена хостов, и код пытается обнаружить такую среду анализа вредоносного ПО.

Найдя имя хоста, возвращающее EAI_NODATA, стадия 3 выполняет для него DNS-запрос. Адрес DNS-сервера находится в расшифрованном блоке первого аргумента по смещению 0x14C7. В данном двоичном файле это 8.8.8.8:53, DNS-сервер Google. Код соединяется с DNS-сервером через сокет, отправляет запрос типа A для случайного имени и разбирает ответ. Единственный допустимый ответ сервера — NXDomain, то есть «несуществующий домен». Получив NXDomain, код переходит к ветви связи с C2-сервером.

Рукопожатие с C2-сервером

Имя хоста и порт C2-сервера читаются из расшифрованного блока данных. Номер порта находится по смещению 0x84, а имя хоста — по смещению 0x4.

Сначала двоичный файл подключается к C2-серверу через сокет, а затем устанавливает SSL/TLS-соединение. SSL/TLS-сертификат, являющийся корневым, также находится в расшифрованном блоке данных по смещению 0x4C7. Двоичный файл использует библиотеку OpenSSL.

Сбор отправляемых данных

После успешного SSL/TLS-подключения к C2-серверу двоичный файл начинает собирать все сведения об устройстве, которые собирается отправить. Данных ОЧЕНЬ много. До отправки удалённому серверу собираются, форматируются, сжимаются и шифруются шесть разных наборов:

• Характеристики устройства

• Сведения о приложениях

• Сведения о местоположении телефона

• Состояние импланта

• Запущенные процессы

• Сообщения журнала об ошибках и информационные сообщения

Характеристики устройства

Для этого набора двоичный файл собирает такие характеристики, как версия Android, серийный номер, модель, температура аккумулятора, st_mode файлов /dev/mem и /dev/kmem, содержимое /proc/net/arp и /proc/net/route и многое другое. Полный список собираемых и отправляемых характеристик документирован здесь.

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

• Вызывает __system_property_get через dlopen(/system/lib/libc.so) и dlsym('__system_property_get').

• Выполняет getprop в popen.

Для получения идентификатора устройства, идентификатора абонента и MSISDN двоичный файл использует shell-команду service call. Чтобы вызвать функцию сервиса через этот API, необходимо знать её код. По сути, код — это номер функции в AIDL-файле, поэтому он может меняться с каждым выпуском Android. Разработчики двоичного файла жёстко задали код сервиса для каждой версии Android SDK от 8 (Froyo) до 29 (Android 10). Например, код getSubscriberId в сервисе iphonesubinfo равен 3 для Android SDK 8–20, 5 для SDK 21 и 7 для SDK 22–29.

Код также собирает подробную сетевую информацию. Например, для каждого интерфейса в каталоге /sys/class/net/ он получает MAC-адрес и IP-адрес.

Сведения о приложениях

Для получения сведений об установленных приложениях двоичный файл отправляет C2-серверу всё содержимое /data/system/packages.xml. Этот XML-файл содержит данные как об установленных пользователем, так и о системных пакетах устройства.

Сведения о местоположении телефона

Для определения физического местоположения устройства двоичный файл запускает в оболочке dumpsys location и полностью отправляет его вывод C2-серверу. Вывод команды dumpsys location содержит, например, последние известные GPS-координаты.

Состояние импланта

Двоичный файл собирает сведения о состоянии эксплойтов и последующих стадий, включая текущую, для отправки C2-серверу. Большинство значений берётся из хеш-таблицы. Серверу отправляются 22 пары значений, в том числе время установки, «счётчик исправлений», build ID и старшие и младшие номера версии двоичного файла. Полный набор отправляемых данных доступен здесь.

Запущенные процессы

Двоичный файл отправляет C2-серверу сведения о каждом запущенном процессе. Он перебирает все каталоги в /proc/ и для каждого процесса отправляет:

• Имя

• Идентификатор процесса (PID)

• PID родительского процесса

• Группы, к которым принадлежит процесс

• Uid

• Gid

Сведения журнала

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

Формирование запроса

После сбора всех наборов данных они сжимаются функцией deflate. Каждое сжатое «сообщение» имеет следующую структуру compressedMessage. messageCode — идентификационный код содержащихся в сообщении сведений. Он вычисляется как CRC32 для 0x10 байт по смещению 0x1CD8 в расшифрованном блоке данных с прибавлением «идентификационного кода».

После отдельного сжатия каждого сообщения или набора данных в структуру compressedMessage порядок байтов меняется для смены endianness, а затем все данные шифруются AES256. Используется ключ из расшифрованного блока данных и IV из 0x10 случайных байт. IV добавляется в начало зашифрованного сообщения.

Данные отправляются серверу POST-запросом. Полный заголовок показан ниже.

Поле Cookie состоит из двух значений расшифрованного блока данных: sid и uid. Значения этих двух ключей в блоке закодированы base64.

Телом POST-запроса служат все собранные и сжатые выше данные. Запрос отправляется C2-серверу через SSL/TLS-соединение.

Разбор ответа

Полученный от сервера ответ разбирается. Код HTTP-ответа, отличный от 200, считается ошибкой. Полученные данные сначала расшифровываются AES256. Ключ находится в расшифрованном блоке данных по смещению 0x48A, а IV передаётся первыми 0x10 байтами ответа. После расшифровки порядок байтов меняется с помощью bswap32, а данные распаковываются функцией inflate. Распакованное тело ответа представляет собой исполняемый файл или последовательность команд.

Файлы cookie C2-сервера

Двоичный файл также сохраняет и удаляет cookie для домена C2-сервера и домена сервера эксплойтов. Сначала удаляется cookie имени хоста сервера эксплойтов с парой имя/значение session=<XXX>. Эта пара жёстко задана в расшифрованном блоке данных двоичного файла. Затем тот же cookie добавляется заново, но с обновлёнными временем последнего доступа и сроком действия.

Выполнение следующей стадии

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

Разработчики стадии 3 намеренно предусмотрели множество способов исполнения кода следующей стадии: последовательность команд для system, ELF-файл разделяемой библиотеки, запускаемый через dlopen и dlsym, и другие. В этом разделе подробно рассматриваются способы, которыми C2-сервер может указать стадии 3 сохранить и начать выполнять следующую стадию.

Если POST-запрос к C2-серверу успешен, код получает исполняемый файл или набор команд и «обрабатывает» его. Ответ разбирается по-разному в зависимости от «кода сообщения» в заголовке. Этот код похож на описанный в разделе «Формирование запроса»: идентификационный код + CRC32 от 0x10 байт по адресу 0x25E30. При обработке ответа двоичный файл снова вычисляет CRC32 этих байтов и вычитает его из кода сообщения. Полученное значение определяет способ обработки содержимого ответа. Большинство кодов различают методы сохранения ответа на устройстве и последующего исполнения.

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

func1 — записывает содержимое ответа в файлы одновременно в каталогах /data/dalvik-cache/arm и /mnt.

Функция выполняет следующее:

1. Записывает буфер ответа в /data/dalvik-cache/arm/<file name keyed by 0x10 in hashtable>.

2. Получает имя файла из mkstemp("/mnt/XXXXXX").

3. Записывает буфер ответа в файл с именем из шага 2 и суффиксом "abc": /mnt/XXXXXXabc.

4. Записывает определённое значение из памяти в файл с именем из шага 2 и суффиксом "xyz": /mnt/XXXXXXxyz. Это значение можно изменить через вторую экспортированную двоичным файлом стадии 3 функцию d.

func2 — создаёт дочерний процесс и внедряет код с помощью ptrace.

Функция создаёт новый процесс, в котором потомок вызывает init из ELF-библиотеки, а родитель внедряет код ответа в дочерний процесс с помощью ptrace. ELF-библиотека, открываемая через dlopen с последующим вызовом init, называется /system/bin/%016lx%016lx, где оба значения являются адресом указателя буфера.

func3 — записывает буфер ответа в файл и задаёт разрешения и атрибуты SELinux.

Функция записывает буфер либо по пути из третьего аргумента, либо по новому сгенерированному пути. При создании временного имени код последовательно перебирает следующие каталоги начиная с /cache; в первом каталоге, для которого удаётся выполнить stat, создаётся временный файл через mkstemp("%s/XXXXXX").

• /cache

• /mnt/secure/asec

• /mnt/secure/staging

• /mnt/secure

• /mnt/obb

• /mnt/asec

• /mnt

• /storage

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

Ниже приведено упрощённое описание обработки ответа C2-сервера в зависимости от кода сообщения:

• 0x270F: вернуть 0.

• 0x2710: ответ представляет собой ELF разделяемой библиотеки (ET_DYN). Вызвать func2, чтобы создать дочерний процесс и внедрить ELF через ptrace.

• 0x2711: ответ представляет собой ELF разделяемой библиотеки (ET_DYN). Сохранить файл как временный на устройстве, затем вызвать для ELF dlopen и dlsym("init"). После этого создаётся дочерний процесс, вызывающий init.

• 0x2712: ответ представляет собой ELF-файл. Файл записывается во временный файл на устройстве. Создаётся дочерний процесс, который выполняет файл через execve.

• 0x2713: ответ представляет собой ELF-файл. Файл записывается во временный файл на устройстве через func3. Создаётся дочерний процесс, который выполняет его через system.

• 0x2714: создать дочерний процесс, вызывающий system(<response contents>).

• 0x2715: ответ представляет собой исполняемый код и отображается через mmap. Определённые последовательности байтов заменяются адресами dlopen, dlsym и функции двоичного файла. Затем код выполняется.

• 0x4E20: если (D1_ENV == 0 и код НЕ может выполнить fstat /data/dalvik-cache/arm/system@framework@boot.oat), перейти в бесконечный сон. Иначе установить переменную в 1.

• 0x4E21: ответ/буфер представляет собой ELF типа ET_DYN, то есть файл .so. Если установлена переменная окружения D1_ENV, вызвать func2, которая создаёт дочерний процесс и внедряет в него код буфера через ptrace. Если D1_ENV не установлена, записать буфер в каталоги dalvik-cache и /mnt через func1.

• 0x4E22: сообщение увеличивает переменную "uninstall_time" в хеш-таблице. Значение по ключу 0xA0 увеличивается на unsigned long, представленный первыми четырьмя байтами буфера ответа.

• 0x4E23: сообщение задаёт переменную "uninstall_time" в хеш-таблице. Значению по ключу 0xA0 присваивается unsigned long, представленный первыми четырьмя байтами буфера ответа.

• 0x4E25: значению по ключу 0x100 в хеш-таблице присваивается unsigned long, представленный первыми четырьмя байтами буфера ответа.

• 0x4E26: если третий аргумент (путь к файлу) функции обработки ответов не равен NULL и ещё не существует, создать каталог, а затем установить его разрешения и атрибуты SELinux из четвёртого и пятого аргументов.

• 0x4E27: записать буфер ответа во временный файл через func3.

• 0x4E28: вызвать rmdir для пути.

• 0x4E29: вызвать rmdir для пути; если он не существует, удалить uierrors.txt.

• 0x4E2A: скопировать дополнительный расшифрованный блок в конец данных, являющихся значением по ключу 0xE0 в хеш-таблице.

• 0x4E2B: если (D1_ENV == 0 и можно выполнить fstat /data/dalvik-cache/arm/system@framework@boot.oat), установить определённые переменные в 1.

• 0x4E2C: если буфер представляет собой 64-разрядный ELF и D1_ENV == 0, вызвать func1 для записи буфера в каталоги dalvik-cache и /mnt.

Заключение

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

Особенно поражает сложность и качество кода стадии 3, если учитывать, что на стадии 2 атакующие использовали только публично известные n-day. На стадии 1 применялся 0-day Google Chrome, на стадии 2 — публичные эксплойты n-day для Android, а на стадии 3 — зрелый, сложный, тщательно спроектированный и реализованный код. Это заставляет предположить, что у субъекта, вероятно, есть дополнительные 0-day-эксплойты для конкретных устройств.

Это пятая часть серии из шести публикаций о наборе уязвимостей, обнаруженных Project Zero в реальных атаках. Продолжение — In The Wild, часть 6: Windows-эксплойты.

Все использованные атакующим уязвимости находятся в V8, JavaScript-движке Chrome, а точнее — в JIT-компиляторе. Хотя классические ошибки безопасности памяти C++ по-прежнему эксплуатируются в реальных атаках против браузеров, уязвимости JIT дают атакующим много преимуществ. Во-первых, обычно они предоставляют более мощные примитивы, которые легко превратить в надёжный эксплойт без отдельной проблемы, например для обхода ASLR. Во-вторых, большинство из них почти взаимозаменяемы, что значительно ускоряет разработку эксплойтов. Наконец, ошибки этого класса позволяют использовать браузерную функцию web workers. Веб-разработчики применяют workers для выполнения дополнительных задач в отдельной среде JavaScript. Каждый worker работает в собственном потоке и имеет собственную кучу V8, благодаря чему эксплуатация становится намного более предсказуемой и стабильной.

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

1. CVE-2017-5070 Уязвимость

Проблема находится в Crankshaft — JIT-движке, который Chrome использовал до TurboFan. Анализатор псевдонимов, применяемый несколькими этапами оптимизации для определения, могут ли два узла ссылаться на один объект, выдаёт неправильный результат, когда один из узлов является константой. Рассмотрим следующий код, извлечённый из одного эксплойта:

Первая строка функции trigger заставляет Crankshaft проверить map объекта global_array (map в V8 описывает «форму» объекта и включает сведения о представлении элементов). Следующая строка может запустить переход представления элементов double -> tagged для local_array. Поскольку компилятор ошибочно считает, что local_array и global_array не могут указывать на один объект, он не аннулирует сохранённое состояние map для global_array и вследствие этого удаляет «избыточную» проверку map в последней строке функции.

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

Исследователь безопасности Цисюнь Чжао (@S0rryMybad) сообщил об ошибке Chrome в мае 2017 года, и она была исправлена в первоначальном выпуске Chrome 59. Исследователь также предоставил renderer-эксплойт. Исправление разрешило анализатору псевдонимов сравнивать константы, только когда оба аргумента являются константами:

Эксплойт 1

Самый ранний обнаруженный нами эксплойт нацелен на Chrome 37–58. Это самый широкий диапазон версий среди всех найденных — почти три года. В отличие от остальных, этот эксплойт содержит отдельную таблицу констант для каждой поддерживаемой сборки браузера.

Автор использует известный подход к эксплуатации смешения типов в JavaScript-движках с промежуточным получением произвольного чтения и записи. Уязвимость используется для реализации примитивов addrof и fakeobj. Эксплойт «конструирует» поддельный ArrayBuffer внутри JavaScript-строки и с помощью этих примитивов получает ссылку на поддельный объект. Поскольку строки JS неизменяемы, поле указателя backing store поддельного ArrayBuffer нельзя изменить. Вместо этого оно заранее направляется на дополнительный ArrayBuffer, который фактически используется для произвольного доступа к памяти. Наконец, эксплойт следует по цепочке указателей, чтобы найти и перезаписать код JIT-скомпилированной функции, хранящийся в области памяти RWX.

Эксплойт представляет собой впечатляющий результат инженерной работы. Например, он содержит небольшой фреймворк для создания поддельных JS-объектов, поддерживающий назначение полей настоящим JS-объектам, поддельным вложенным объектам, tagged-целым и прочему. Поскольку ошибку можно запустить только один раз на JIT-скомпилированную функцию, при каждом вызове addrof или fakeobj эксплойт динамически создаёт новый набор необходимых объектов и функций с помощью eval.

Автор также приложил значительные усилия для повышения надёжности: на каждом небольшом этапе есть sanity check; addrof сохраняет все раскрытые указатели, и перед обращением к поддельному объекту эксплойт проверяет, что они всё ещё действительны; fakeobj создаёт гигантскую строку для хранения содержимого подготовленного объекта, чтобы она была выделена в large object space, где сборщик мусора не перемещает объекты. И, конечно, эксплойт выполняется внутри web worker.

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

Эксплойт 2

Второй эксплойт той же уязвимости нацелен на Chrome 47–58, то есть поддиапазон версий предыдущего эксплойта, причём сервер эксплойтов всегда отдаёт предпочтение второму. Определение версии менее строгое, и используются всего три разные таблицы констант: для Chrome 47–49, 50–53 и 54–58.

Общий подход похож, однако новый эксплойт, по-видимому, переписан с нуля с упором на простоту и краткость: его размер вдвое меньше предыдущего. addrof реализован так, чтобы одновременно раскрывать указатели трёх объектов, и используется всего один раз, поэтому динамическое создание trigger-функций больше не нужно. Для хранения содержимого поддельных объектов эксплойт использует изменяемые typed array в куче вместо JS-строк; следовательно, дополнительный уровень косвенности в виде ещё одного ArrayBuffer не требуется. Ещё одно заметное изменение — использование объекта RegExp для выполнения кода. Возможное преимущество в том, что, в отличие от JS-функции, которую нужно многократно вызвать для JIT-компиляции, регулярное выражение превращается в нативный код уже в конструкторе.

Хотя эксплойты могли быть написаны после публичного раскрытия проблемы, они сильно отличаются от публичного эксплойта как архитектурой, так и деталями реализации. Атакующий тщательно исследовал ошибку: например, его trigger-функция намного прямолинейнее, чем в публичном proof of concept.

2. CVE-2020-6418 Уязвимость

Это проблема моделирования побочных эффектов в TurboFan. Функция InferReceiverMapsUnsafe предполагает, что узел JSCreate может изменять только map своего выходного значения. На самом деле узел способен вызвать обращение к свойству параметра new_target, наблюдаемое пользовательским JavaScript, если new_target является proxy-объектом. Поэтому атакующий может неожиданно изменить, например, представление элементов JS-массива и вызвать смешение типов, похожее на рассмотренное выше:

Call reducer, то есть оптимизатор, для Array.prototype.pop вызывает InferReceiverMapsUnsafe, которая помечает результат вывода как надёжный, а значит, не требующий проверки во время выполнения. Когда уязвимой функции передаётся proxy-объект, он запускает переход представления элементов tagged -> double. Затем pop извлекает элемент double и интерпретирует его как tagged-указатель.

Обратите внимание, что атакующий не может вызвать функцию массива напрямую, поскольку для выражения array.pop() компилятор добавил бы дополнительную проверку map при чтении свойства, запланированную после того, как обработчик proxy изменил массив.

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

Дополнительные сведения о проблеме и версии эксплойта Exodus Intel приведены в их публикации.

Эксплойт 1

На этот раз встроенного списка поддерживаемых версий браузера нет; подходящие константы для Chrome 60–63 определяются на стороне сервера.

Эксплойт использует довольно экзотический подход: он реализует только функцию смешения в направлении double -> tagged, то есть примитив fakeobj, и использует побочный эффект pop для раскрытия указателя на внутренний объект hole. Функция pop заменяет «извлечённое» значение на hole, но из-за того же смешения записывает указатель вместо специального битового шаблона для массивов double.

Эксплойт использует раскрытый указатель и fakeobj для реализации примитива утечки данных, способного «переживать» сборку мусора. Сначала он получает ссылки на два других внутренних объекта — class_start_position и class_end_position, приватные символы, поскольку смещение между ними и hole фиксировано. Приватные символы — специальные идентификаторы, с помощью которых V8 хранит скрытые свойства внутри обычных JS-объектов. В частности, эти два символа обозначают начальный и конечный индексы подстроки в исходном коде скрипта, представляющей тело класса. Когда JSFunction::ToString вызывается для конструктора класса и строит подстроку, он не проверяет границы «доверенных» индексов; следовательно, атакующий может изменить их и раскрывать произвольные фрагменты данных в куче V8.

Полученные данные сканируются в поисках значений, необходимых для создания поддельного typed array: map, fixed array, указателей backing store и прочего. Такой подход позволяет создать полностью корректный поддельный объект. Поскольку объект расположен в области памяти за пределами кучи V8, эксплойт также должен создать поддельный заголовок MemoryChunk и marking bitmap, чтобы сборщик мусора пропустил подготовленные объекты и не вызвал сбой.

Наконец, эксплойт перезаписывает код JIT-скомпилированной функции полезной нагрузкой и выполняет её.

Автор реализовал обширные sanity checks. Например, примитив утечки данных повторно используется, чтобы проверить, не переместил ли сборщик мусора критические объекты. При неудаче worker с эксплойтом завершается до того, как сможет вызвать сбой. Впечатляет, что даже когда мы вручную добавляли вызовы GC в критические участки эксплойта, в большинстве случаев он всё равно корректно завершался.

Эксплойт применяет интересный метод определения, была ли trigger-функция JIT-скомпилирована:

Во время компиляции TurboFan встраивает builtin-функцию Number. Это изменение отражается в стеке вызовов JS. Поэтому атакующий может просканировать трассировку стека изнутри функции, вызываемой Number, и определить состояние компиляции.

Эксплойт перестал работать в Chrome 64 из-за изменения, объединившего оба индекса тела класса в одном внутреннем объекте. Хотя изменение затронуло лишь небольшую деталь эксплойта и имело очевидный обход, рассмотренный ниже, субъект решил отказаться от этого 0-day и перейти к эксплойту CVE-2019-5782. Это позволяет предположить, что атакующему уже была известна третья уязвимость примерно во время выхода Chrome 64, то есть она также использовалась как 0-day.

Эксплойт 2

После того как CVE-2019-5782 перестала эксплуатироваться, субъект вернулся к этой уязвимости. Однако к тому времени в Chrome попал ещё один коммит, запретивший TurboFan оптимизировать builtin-функции, вызываемые через Function.prototype.call или похожие функции. Поэтому trigger-функцию пришлось обновить:

Сделав результат Reflect.construct аргументом вызова pop, атакующий может переместить соответствующий узел JSCreate после проверки map, вызванной загрузкой свойства.

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

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

Эта версия нацелена на Chrome 68–72. Её сломал коммит, включивший защиту W^X для областей JIT. И снова, поскольку в renderer оставались похожие отображения RWX, связанные с WebAssembly, эксплойт можно было легко исправить. Тем не менее атакующий решил сосредоточиться на эксплойте CVE-2019-13764.

Эксплойты 3 и 4

После исправления CVE-2019-13764 субъект снова вернулся к этой уязвимости. Новый эксплойт обходит W^X, заменяя JIT-скомпилированную JS-функцию функцией WebAssembly в качестве цели перезаписи для исполнения кода. Это единственное значимое изменение автора.

Эксплойт 3 — единственный обнаруженный нами на Windows-сервере, а эксплойт 4 по существу является тем же эксплойтом, адаптированным для Android. Любопытно, что на Android-сервере он появился лишь после выхода исправления уязвимости. Значительное число числовых и строковых литералов было изменено, а вызов pop в trigger-функции заменён вызовом shift. Вероятно, этими изменениями субъект пытался избежать обнаружения по сигнатурам.

Эксплойты использовались против Chrome 78–79 в Windows и 78–80 в Android, пока уязвимость наконец не исправили.

Публичный эксплойт, представленный Exodus Intel, использует совершенно другой подход и злоупотребляет различием размеров элементов double и tagged-указателей. Когда та же ошибка применяется к функции Array.prototype.push, смещение backing store для нового элемента вычисляется неправильно, поэтому произвольные данные записываются за конец массива. В таком случае атакующему не нужно создавать поддельные объекты для произвольного чтения и записи, что сильно упрощает эксплойт. Однако на 64-разрядных системах этот подход применим только начиная с Chrome 80, где появилась компрессия указателей. Хотя Chrome в Android по-прежнему работает в 32-разрядном режиме ради снижения расхода памяти, проверки user agent в эксплойтах показывают, что субъект также нацеливался на процессы webview, возможно 64-разрядные.

3. CVE-2019-5782 Уязвимость

CVE-2019-5782 — проблема в модуле typer TurboFan. Во время компиляции typer выводит возможный тип каждого узла графа функции по набору правил языка. Последующие этапы оптимизации полагаются на эти сведения и могут, например, удалить критичную для безопасности проверку, когда предсказанный тип делает её избыточной. Поэтому несоответствие между выведенным типом и фактическим значением способно привести к проблемам безопасности.

Обратите внимание, что здесь понятие типа сильно отличается, например, от типов C++. Тип TurboFan может представляться диапазоном чисел или даже конкретным значением. Дополнительные сведения об ошибках typer приведены в предыдущей публикации.

В данном случае неправильный тип создаётся для выражения arguments.length, то есть числа аргументов, переданных функции. Компилятор назначает ему целочисленный диапазон [0; 65534], правильный для обычного вызова, однако для Function.prototype.apply такое ограничение не действует. Атакующий использовал несоответствие для удаления проверки границ и доступа к данным за концом массива:

Цисюнь Чжао использовал ту же уязвимость на Tianfu Cup и сообщил о ней Chrome в ноябре 2018 года. Публичный отчёт включает renderer-эксплойт. Исправление, попавшее в Chrome 72, просто расширило диапазон свойства length.

Эксплойт

Обнаруженный эксплойт нацелен на Chrome 63–67. Его ход немного необычен, поскольку для получения произвольного чтения и записи не используются typed array. Атакующий пользуется тем, что V8 линейно выделяет объекты в new space, и заранее вычисляет смещения между ними. Уязвимость запускается лишь один раз, чтобы повредить свойство length массива tagged-указателей. Затем повреждённый массив можно многократно использовать для перезаписи поля elements массива неупакованных double произвольным JS-объектом, получая необработанный доступ к содержимому этого объекта. Примечательно, что подход не требует даже ручной арифметики указателей. Как обычно, в конце эксплойт перезаписывает код JS-функции полезной нагрузкой.

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

Как читатель мог заметить, эксплойт перестал работать задолго до исправления ошибки. Причина — одно из усилений защиты V8 от спекулятивных атак по сторонним каналам, сломавшее метод удаления проверки границ. Вскоре защиту отключили для настольных платформ и заменили изоляцией сайтов; поэтому публичный эксплойт, применявший тот же метод, успешно использовали против Chrome 70 в Windows во время соревнования.

У публичного и закрытого эксплойтов мало общего, кроме самой ошибки и метода BCE, широко известного как минимум с 2017 года. Публичный эксплойт превращает доступ за границами в смешение типов, а затем следует более старому подходу с созданием поддельного объекта array buffer для выполнения кода.

4. CVE-2019-13764

Эта более сложная проблема typer возникает, когда TurboFan не отражает возможное значение NaN в типе индукционной переменной. Ошибку можно запустить следующим кодом:

Уязвимость и эксплойт для Chrome 73–79 подробно рассмотрены в предыдущей публикации. Существует и более ранняя версия эксплойта для Chrome 69–72; единственное отличие в том, что новая версия перешла с JS JIT-функции на функцию WASM в качестве цели перезаписи.

Однако интереснее сравнение с эксплойтом предыдущей typer-ошибки, CVE-2019-5782. Разработчик уделил намного больше внимания стабильности нового эксплойта, хотя обе уязвимости в этом отношении идентичны. Вернулась обёртка web worker, а эксплойт не повреждает массивы tagged-элементов, чтобы избежать сбоев GC. Кроме того, он больше не полагается полностью на заранее вычисленные смещения между объектами в new space. Например, для раскрытия указателя на JS-объект атакующий помещает его между значениями-маркерами, а затем сканирует память в поисках совпадающего шаблона. Наконец, снова увеличено количество sanity checks.

Стоит также отметить, что новый метод эксплуатации ошибки typer работал против Chrome в Android несмотря на защиту от атак по сторонним каналам и мог бы «возродить» эксплойт CVE-2019-5782.

Заключение

Временная диаграмма и последовательные изменения версий эксплойтов показывают, что как минимум три из четырёх уязвимостей — CVE-2020-6418, CVE-2019-5782 и CVE-2019-13764 — использовались как 0-day.

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

За последние несколько лет безопасность JIT-движков привлекла большое внимание сообщества. В 2015 году, когда вышел Chrome 37, эксплойт CVE-2017-5070 считался бы значительно опередившим своё время. Напротив, если не учитывать стабильность, эксплойт последней typer-ошибки мало отличается от эксплойтов, которые энтузиасты создавали для JavaScript-задач на CTF в 2019 году. Такое внимание, вероятно, влияет и на среднее время жизни JIT-уязвимости, а значит, в будущем может заставить атакующих перейти к другим классам ошибок.

Это третья часть серии из шести публикаций о наборе уязвимостей, обнаруженных Project Zero в реальных атаках. Продолжение — In The Wild, часть 4: Android-эксплойты.

Для целых чисел V8 идёт ещё дальше и отслеживает возможный диапазон узлов. Главная причина в том, что, хотя спецификация ECMAScript определяет Number как 64-разрядный тип с плавающей точкой, внутри TurboFan всегда пытается использовать наиболее эффективное представление в данном контексте: 64-разрядное целое, 31-разрядное tagged-целое и так далее. Сведения о диапазоне применяются и в других оптимизациях. Например, компилятор способен определить, что в следующем фрагменте ветвь никогда не выполняется, и полностью удалить оператор if:

Теперь представим ошибку, заставляющую TurboFan считать, что функция vuln() возвращает значение в диапазоне [0; 2], тогда как фактический диапазон равен [0; 4]. Рассмотрим код:

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

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

Описанный класс ошибок — главная тема публикации, а удаление проверок границ является самым распространённым методом его эксплуатации. Классический пример такой уязвимости — ошибка off-by-one в правиле typer для String.indexOf, обнаруженная Стивеном Рёттгером.

Уязвимость typer не обязана сразу вызывать неправильное вычисление целочисленного диапазона и доступ OOB, поскольку можно заставить компилятор распространить ошибку. Например, если vuln() возвращает неожиданное логическое значение, его легко превратить в неожиданное целое:

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

В определённый момент этот класс уязвимостей стал чрезвычайно популярен, поскольку сразу давал атакующему невероятно мощный и надёжный примитив эксплуатации. Наш коллега по Project Zero Марк Бранд использовал его в своей полной цепочке Chrome-эксплойта. Ошибки этого класса появлялись на нескольких CTF и соревнованиях по эксплуатации. В результате в прошлом году команда V8 выпустила усиление защиты, призванное не допустить злоупотребления удалением проверок границ. Вместо удаления проверок компилятор стал помечать их как «прерывающие», поэтому в худшем случае атакующий может вызвать лишь SIGTRAP.

Анализ индукционных переменных

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

Теперь представим, что компилятор обрабатывает следующий JavaScript-код:

Если кратко, когда цикл признан возрастающим, нижняя граница initial становится нижней границей i, а верхняя вычисляется как сумма верхних границ bound и increment. Для убывающих циклов есть похожая ветвь, а для переменных, способных и возрастать, и убывать, — особый случай. Переменная цикла называется в методе phi, поскольку TurboFan работает с промежуточным представлением в форме статического однократного присваивания.

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

• К нему принадлежат +Infinity и -Infinity, но не NaN и -0.

• Тип не замкнут относительно сложения, то есть сумма двух целых не всегда является целым. В частности, +Infinity + -Infinity даёт NaN.

Таким образом, для следующего цикла алгоритм выводит тип индукционной переменной (-Infinity; +Infinity), хотя фактическим значением после первой итерации будет NaN:

Этой одной строки достаточно для запуска проблемы. Автору эксплойта пришлось внести лишь два небольших изменения: (1) параметризовать increment, чтобы значение i при первых вызовах в интерпретаторе соответствовало будущему выведенному типу, и (2) добавить переменную, гарантирующую завершение цикла. После деобфускации соответствующая часть trigger-функции выглядит так:

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

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

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

Первое примечательное преобразование происходит на втором этапе. TurboFan решает, что наиболее подходящим представлением i в этот момент является 64-разрядное целое, поскольку выведенный диапазон полностью помещается в int64_t, и создаёт инструкцию CVTTSD2SI для преобразования аргумента double. Так как NaN не помещается в целочисленный диапазон, инструкция возвращает «неопределённое целочисленное значение» -0x8000000000000000. На следующем этапе компилятор определяет, что можно использовать ещё более узкий тип int32_t. Он отбрасывает старшее 32-разрядное слово i, предполагая, что для значений данного диапазона это равнозначно вычитанию 0x100000000, а затем дополнительно вычитает 0x7fa. Оставшиеся две операции просты, однако может возникнуть вопрос, почему атакующий не мог заставить компилятор вывести нужный одноэлементный тип сразу на втором этапе. Ответ находится в этапе оптимизации constant-folding reducer.

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

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

Когда аргумент известен как целочисленная константа меньше 16, компилятор встраивает процедуру создания массива и разворачивает цикл инициализации элементов. ReduceJSCreateArray не полагается на constant-folding reducer и реализует собственный, менее строгий эквивалент, который лишь сравнивает верхнюю и нижнюю границы выведенного типа. К сожалению, даже после folding функция продолжает использовать исходный узел аргумента. Свёрнутое значение применяется при инициализации backing store, тогда как свойство length массива задаётся исходным узлом. Следовательно, если передать конструктору значение, полученное на пятом этапе, он вернёт массив с отрицательной длиной и backing store, вмещающим 13 элементов. Поскольку проверки границ реализованы как беззнаковые сравнения, подготовленный массив позволит обращаться к данным далеко за его концом. На самом деле сработало бы любое положительное значение, превышающее предсказанную версию.

Остальная часть trigger-функции приведена ниже:

Атакующий заставляет TurboFan расположить данные, необходимые для дальнейшей эксплуатации, непосредственно рядом с повреждённым массивом и использовать для backing store тип элементов double, поскольку он наиболее удобен для работы с данными за границами кучи V8.

С этого момента эксплойт следует тому же алгоритму, который уже несколько лет используют публичные V8-эксплойты:

• Найти необходимые указатели и поля объектов с помощью сопоставления шаблонов.

• Создать примитив произвольного доступа к памяти с помощью дополнительного JavaScript-массива и ArrayBuffer.

• Проследовать по цепочке указателей от экземпляра модуля WebAssembly и найти доступную для записи и исполнения страницу памяти.

• Перезаписать тело функции WebAssembly внутри страницы полезной нагрузкой атакующего.

• Наконец, выполнить её.

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

Поскольку подавляющее большинство Chrome-эксплойтов, которые мы видели в Project Zero, поступает с соревнований или через VRP, самое заметное отличие данного эксплойта — его упор на стабильность и надёжность. Вот несколько примеров. Почти весь эксплойт выполняется внутри web worker, то есть имеет отдельную среду JavaScript и работает в собственном потоке. Это значительно уменьшает вероятность случайного сбоя из-за сборщика мусора при несогласованном состоянии кучи. Часть главного потока отвечает только за перезапуск worker при неудаче и отправку сведений о состоянии серверу атакующего. Эксплойт пытается дополнительно сократить окно сбоев GC, как можно быстрее восстанавливая исходное значение каждого повреждённого поля. Кроме того, он уже на раннем этапе использует примитив OOB-доступа для проверки сведений об архитектуре процессора из заголовка user agent. Наконец, автор явно стремился минимизировать число жёстко заданных констант. Несмотря на поддержку широкого диапазона версий Chrome, эксплойт зависит от единственного зависящего от версии смещения — смещения от экземпляра WASM до указателя исполняемой страницы.

Исправление 1

Хотя есть свидетельства первоначального использования уязвимости как 0-day, к моменту получения эксплойта она уже была исправлена. Исследователи безопасности Соён Пак и Вэнь Сюй сообщили о проблеме Chrome в ноябре 2019 года, ей присвоили CVE-2019-13764. Предоставленный в отчёте proof of concept показан ниже:

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

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

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

Код предполагает, что переменная цикла может стать NaN, только если сумма или разность initial и increment равна NaN. На первый взгляд это разумное предположение. Проблема возникает потому, что значение increment можно изменить внутри цикла, что неочевидно из эксплойта, но продемонстрировано в отправленном Chrome proof of concept. Typer учитывает эти изменения и отражает их в вычисленном типе increment. Поэтому атакующий может, например, прибавлять отрицательное increment к i, пока последняя не станет -Infinity, затем изменить знак increment и снова заставить цикл создать NaN, как показано ниже:

Таким образом, чтобы «оживить» весь эксплойт, атакующему достаточно изменить пару строк в trigger.

Исправление 2

Об обнаруженном варианте сообщили Chrome в феврале вместе с найденным в эксплойте методом эксплуатации. На этот раз исправление выбрало более консервативный подход: функция прекращает работу, как только typer обнаруживает, что increment может быть Infinity.

Кроме того, ReduceJSCreateArray обновили, чтобы для свойства length и ёмкости backing store всегда использовалось одно значение, тем самым сделав описанный метод эксплуатации бесполезным.

К сожалению, новое исправление содержало непреднамеренное изменение, создавшее другую проблему безопасности. Если посмотреть исходный код TypeInductionVariablePhi до исправлений, видно, что он проверяет, ограничен ли тип increment константным нулём. В этом случае индукционной переменной назначается тип initial. Второе исправление перенесло проверку выше строки, убеждающейся, что initial является целым. Однако в JavaScript прибавление или вычитание нуля не обязательно сохраняет тип, например:

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

Мы решили проверить, насколько трудно найти замену методу ReduceJSCreateArray и эксплуатировать новую проблему. Задача оказалась намного проще ожидаемого, поскольку вскоре мы нашли эту прекрасную публикацию Жереми Фетиво, где описан обход первоначального усиления против удаления проверок границ. Если кратко, в зависимости от того, встречал ли движок попытку обращения к несуществующему элементу массива во время выполнения функции в интерпретаторе, он поручает компилятору создать узел CheckBounds или NumberLessThan, а усиление защиты охватывает только первый. Следовательно, атакующему нужно лишь добиться обращения функции к отсутствующему элементу массива во время одного из первых нескольких вызовов.

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

И снова метод требует целого с неправильно вычисленным диапазоном, поэтому обновлённая trigger-функция в основном состоит из разных преобразований типов:

Несоответствие числа 30 и строки «30» возникает на пятом этапе. Следующая операция представляется узлом SpeculativeSafeIntegerAdd. Typer знает, что при встрече нечислового аргумента этот узел немедленно запускает деоптимизацию. Поэтому все нечисловые элементы типа аргумента можно игнорировать. Неожиданное целочисленное значение, которое, очевидно, не вызывает деоптимизацию, позволяет создать ошибочный диапазон. В итоге компилятор на основании наблюдаемого диапазона удаляет узел NumberLessThan, который должен защищать обращение к элементу в последней строке.

Исправление 3

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

• Расширено усиление защиты доступа к элементам, которое теперь предотвращает злоупотребление узлами NumberLessThan.

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

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

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

Заключение

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

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

Это вторая часть серии из шести публикаций о наборе уязвимостей, обнаруженных Project Zero в реальных атаках. Продолжение — In The Wild, часть 3: Chrome-эксплойты.

Интерфейс Windows GDI поддерживает старый формат шрифтов Type 1, разработанный Adobe примерно в 1985 году и популярный преимущественно в 1990-х и начале 2000-х. В Windows такие шрифты представлены парой файлов .PFM (Printer Font Metric) и .PFB (Printer Font Binary), причём PFB сочетает текстовый синтаксис PostScript и двоично закодированные инструкции CharString, описывающие формы глифов. GDI также поддерживает малоизвестное расширение Type 1 под названием «Multiple Master Fonts». Эта функция никогда не была особенно популярной, но значительно усложняет логику растеризации текста и исторически служила источником множества программных ошибок, например в операторе blend.

В Windows 8.1 и более ранних версиях разбор таких шрифтов выполняется в драйвере ядра atmfd.dll, доступном через графические системные вызовы win32k.sys, и потому представляет поверхность атаки для повышения привилегий. В Windows 10 код перенесли в ограниченный процесс пользовательского режима fontdrvhost.exe, сделав его значительно менее привлекательной целью. Поэтому найденный в реальных атаках эксплойт имел отдельный путь выхода из песочницы для Windows 10, рассмотренный в разделе 2, «CVE-2020-1027». Как ни странно, шрифтовый эксплойт явно поддерживал Windows 8 и 8.1, хотя эти платформы предлагают политику отключения win32k, которую использует Chrome, поэтому затронутый код не должен быть достижим из процессов renderer. Причина неясна; возможно, тот же privesc-эксплойт применялся против другого клиентского ПО, не только Chrome, либо был разработан до включения win32k lockdown по умолчанию в Chrome, то есть до 2015 года.

Тем не менее последующий анализ основан на 64-разрядной Windows 8.1 с исправлениями марта 2020 года — последней затронутой версии на момент обнаружения эксплойта.

Ошибка шрифта №1

Первая уязвимость находилась в обработке PostScript-объекта /VToHOrigin. Полагаю, этот объект определялся только в одном из ранних проектов расширения Multiple Master, поскольку сейчас он почти не документирован и официальные сведения о нём найти трудно. Функция-обработчик ключевого слова VToHOrigin находится по смещению 0x220B0 в atmfd.dll, а благодаря публичным символам fontdrvhost.exe известно её имя — ParseBlendVToHOrigin. Чтобы понять ошибку, рассмотрим следующий псевдокод функции, из которого для ясности удалены несущественные части:

Итак, функция инициализирует в стеке numMasters указателей, затем читает из входного потока массив значений с фиксированной точкой того же размера и записывает каждое значение по соответствующему указателю. Первопричина заключалась в том, что numMasters мог принимать любое значение от 0 до 16, а массивы ptrs и values содержали всего по два элемента. Поэтому при трёх и более master, указанных в шрифте, обращения к ptrs[2] и values[2] и более крупным индексам повреждали память стека. В исследованной мной сборке x64 кадр стека функции имел следующее расположение:

Зелёные строки обозначают контролируемые пользователем локальные массивы, а красные — внутренние данные управления потоком, которые можно повредить. Интересно, что массивы разделялись сохранённым регистром RDI и адресом возврата, вероятно из-за оптимизации компилятора и малой длины values. Прямое переполнение адреса возврата здесь не особенно полезно, поскольку он всегда перезаписывается неисполняемым адресом. Однако если пока проигнорировать его и продолжить повреждение стека, следующий указатель ptrs[4] перекрывается с контролируемыми данными в values[0] и values[1], а код записывает по нему целое values[4]. Это классическое условие write-what-where в ядре.

После первой контролируемой записи 32-разрядного значения следующая итерация цикла пытается записать values[5] по адресу, составленному как ((values[3]<<32)|values[2]). Эта вторая запись write-what-where позволяет атакующему безопасно выйти из функции. К этому моменту адрес возврата неизбежно повреждён, и единственный способ завершить работу без сбоя ядра — обратиться к недопустимой памяти ring 3. Такое исключение перехватывается универсальным catch-all-обработчиком, активным на протяжении всего разбора шрифта в atmfd, и выполнение безопасно возвращается вызывающей стороне пользовательского режима. Это делает уязвимость очень надёжной в эксплуатации: сразу за примитивом write-what-where следует чистый выход без нежелательных побочных эффектов между ними.

Proof of concept легко создать из любого существующего шрифта Type 1, перекомпилировав его, например с помощью утилит detype1 + type1 из AFDKO, и добавив два объекта в файл .PFB. Минимальный текстовый пример показан ниже:

Первая выделенная строка устанавливает numMasters в 5, а вторая запускает запись 0x42424242, представленного как 16962.25882, по адресу 0xffffffff41414141, составленному из 16705.25490 и -0.00001. Сбой можно воспроизвести, поместив PFB- и PFM-файлы в один каталог и открыв PFM в стандартной программе просмотра шрифтов Windows. После этого в отладчике ядра должен появиться следующий bugcheck:

Ошибка шрифта №2

Вторая проблема была обнаружена в обработке объекта /BlendDesignPositions, определённого в документе Adobe Font Metrics File Format Specification 1998 года. Его обработчик расположен по смещению 0x21608 в atmfd.dll, а символы fontdrvhost.exe снова раскрывают внутреннее имя — SetBlendDesignPositions. Рассмотрим C-подобный псевдокод:

2. Проблема CSRSS в Windows 10 (CVE-2020-1027) Предыстория

Client/Server Runtime Subsystem, или csrss.exe, — часть подсистемы Win32, работающая в пользовательском режиме. До Windows NT 4.0 CSRSS отвечала за весь графический пользовательский интерфейс; сейчас она выполняет задачи, связанные, например, с управлением процессами и потоками.

csrss.exe — процесс пользовательского режима с привилегиями SYSTEM. По умолчанию каждое Win32-приложение при запуске открывает соединение с CSRSS. Значительное число функций Windows API зависит от этого соединения, поэтому даже самые строгие песочницы приложений, включая Chromium, не могут заблокировать его без проблем со стабильностью. Это делает CSRSS привлекательным вектором атак повышения привилегий.

Взаимодействие с сервером подсистемы выполняется через механизм ALPC, поверх которого ОС предоставляет высокоуровневый CSR API. Основная функция API называется ntdll!CsrClientCallServer. Она вызывает выбранную функцию CSRSS и при необходимости получает результат:

Параметр ApiNumber определяет выполняемую функцию. ApiMessage — указатель на соответствующий объект сообщения размером DataLength, а CaptureBuffer — указатель на буфер в специальной области общей памяти, создаваемой при инициализации соединения. CSRSS использует общую память для передачи больших и/или динамических структур, например строк. ApiMessage может содержать указатели на объекты внутри CaptureBuffer, а API преобразует эти указатели между виртуальными адресными пространствами клиента и сервера.

Подробное описание внутреннего устройства CSRSS приведено в этой серии публикаций.

Один из модулей CSRSS, sxssrv.dll, реализует поддержку side-by-side assemblies. Технология side-by-side assembly (SxS) — стандарт для исполняемых файлов, предназначенный прежде всего для устранения проблем, например конфликтов версий, возникающих при использовании динамически подключаемых библиотек. В SxS Windows хранит несколько версий DLL и загружает их по требованию. Приложение может включать side-by-side manifest — специальный XML-документ с точным описанием зависимостей. Пример манифеста приложения приведён ниже:

Ошибка

Уязвимость обнаружена в функции sxssrv!BaseSrvSxsCreateActivationContext с номером API 0x10017. Она разбирает манифест приложения и все его, возможно транзитивные, зависимости в двоичную структуру данных activation context. Текущий activation context определяет объекты и библиотеки, которые следует перенаправить на конкретную реализацию.

Соответствующий объект ApiMessage содержит несколько параметров UNICODE_STRING, например имя приложения и путь к хранилищу assembly. UNICODE_STRING — известная изменяемая строковая структура с отдельным полем ёмкости (MaximumLength) backing store:

BaseSrvSxsCreateActivationContext начинает с проверки строковых параметров:

CsrValidateMessageBuffer объявлена следующим образом:

Функция проверяет, что 1) указатель *Buffer ссылается на данные внутри связанного capture buffer, 2) выражение *Buffer + ElementCount * ElementSize не вызывает целочисленного переполнения и 3) не выходит за конец capture buffer.

Как видно, размер буфера для проверки вычисляется по полю Length, а не MaximumLength. Это было бы безопасно, если бы строки использовались только как входные параметры. К сожалению, строка по смещению 0x120 от начала ApiMessage, которую мы будем называть ApplicationName, может повторно использоваться и как выходной параметр. Затронутый стек вызовов выглядит так:

При вызове BaseSrvSxsCreateActivationContextFromStructEx она инициализирует экземпляр структуры SXS_GENERATE_ACTIVATION_CONTEXT_PARAMETERS указателем на буфер ApplicationName и непроверенным значением MaximumLength в качестве размера буфера:

Затем sxs!SxsGenerateActivationContext передаёт эти значения в ACTCTXGENCTX:

В конечном счёте sxs!CNodeFactory::XMLParser_Element_doc_assembly_assemblyIdentity вызывает memcpy, способную выйти за конец capture buffer:

Исходные данные для вызова memcpy поступают из параметра name главного узла assemblyIdentity в манифесте.

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

Хотя уязвимость присутствовала и в старых версиях Windows, эксплойт нацелен только на Windows 10. Поддерживаются все основные сборки вплоть до 18363.

В результате уязвимости атакующий может вызвать memcpy с полностью контролируемыми содержимым и размером. Это один из лучших первоначальных примитивов, которые может дать ошибка повреждения памяти, однако есть потенциальная проблема. Пока кажется, что ошибка позволяет записать данные либо за конец capture buffer в области общей памяти, которую процесс в песочнице и так может изменять, либо за конец общей области, рядом с которой довольно трудно надёжно создать «полезное» выделение. К счастью для атакующего, уязвимый код фактически работает с копией исходного capture buffer. csrsrv!CsrCaptureArguments создаёт её, чтобы избежать проблем из-за конкурентного изменения содержимого буфера, а копия выделяется в обычной куче.

Логичным первым шагом эксплойта была бы утечка данных для обхода ASLR. Однако следующие особенности архитектуры Windows и CSRSS делают её ненужной:

• Windows рандомизирует адреса модулей один раз при загрузке, а csrss.exe является обычным процессом пользовательского режима. Поэтому для атак повторного использования кода можно применять модули, загруженные и в csrss.exe, и в скомпрометированный процесс песочницы, например ntdll.dll.

• При инициализации csrss.exe сообщает клиентским процессам свой виртуальный адрес общей области, чтобы те могли корректировать указатели для вызовов API. Смещение между «локальным» и «удалённым» адресами хранится в ntdll!CsrPortMemoryRemoteDelta. Поэтому атакующий может хранить, например, необходимые для атаки поддельные структуры в общем отображении по предсказуемому адресу.

Эксплойт должен обойти и другую защиту — Microsoft Control Flow Guard, которая значительно усложняет переход к цепочке гаджетов повторного использования кода через косвенный вызов функции. Атакующий решил воспользоваться неспособностью CFG защищать адреса возврата в стеке и так получить управление указателем инструкций. Полный алгоритм выглядит следующим образом:

1. Подготовить кучу. Эксплойт выполняет предварительный вызов CreateActivationContext со специально сформированным манифестом для приведения кучи в предсказуемое состояние. Он содержит XML-узел с множеством атрибутов вида aa:aabN="BB...BB". Манифест второго вызова, фактически запускающего уязвимость, содержит похожие атрибуты другого размера.

2. Реализовать write-what-where. Переполнение буфера используется для перезаписи содержимого узлов XMLParser::_MY_XML_NODE_INFO. _MY_XML_NODE_INFO может содержать указатель на внутренний символьный буфер. Если при дальнейшем разборе текущий элемент является числовой символьной сущностью, то есть строкой вида ሴ, парсер вызывает XMLParser::CopyText, чтобы сохранить декодированный символ во внутреннем буфере активного узла _MY_XML_NODE_INFO. Следовательно, перезапись нескольких узлов позволяет эксплойту записывать данные любого размера по контролируемому адресу.

3. Перезаписать список загруженных модулей. Полученный на предыдущем этапе примитив изменяет указатель на список загруженных модулей в структуре PEB_LDR_DATA внутри ntdll.dll. Это возможно, поскольку атакующий уже получил базовый адрес библиотеки из процесса песочницы. Поддельный список модулей состоит из множества записей LDR_MODULE и хранится в области общей памяти. Неофициальное определение структуры показано ниже:

При создании нового потока функция ntdll!LdrpInitializeThread проходит по списку модулей и при наличии нужных флагов запускает функцию из поля EntryPoint с BaseAddress в качестве первого аргумента. Вызов EntryPoint всё ещё защищён CFG, поэтому перейти к ROP-цепочке пока нельзя. Однако атакующий получает возможность выполнить произвольную последовательность вызовов функций с одним аргументом.

4. Запустить новый поток. Эксплойт намеренно вызывает разыменование null-указателя. Обработчик исключений в csrss.exe перехватывает его и создаёт задачу отчёта об ошибке в новом потоке через csrsrv!CsrReportToWerSvc.

5. Восстановить список модулей. После начала обработки поддельного списка важно вернуть PEB_LDR_DATA в исходное состояние, чтобы избежать сбоев других потоков. Атакующий обнаружил, что пара вызовов ntdll!RtlPopFrame и ntdll!RtlPushFrame позволяет скопировать 8-байтовое значение с одного заданного адреса на другой. Поддельный список модулей начинается с такой пары, исправляющей структуру данных loader.

6. Раскрыть регистр стека. На этом этапе эксплойт в полной мере использует область общей памяти. Сначала он вызывает setjmp, чтобы раскрыть состояние регистров в общую область. Следующая запись модуля указывает на саму себя, поэтому выполнение входит в бесконечный цикл вызовов NtYieldExecution. Тем временем процесс песочницы обнаруживает изменение данных в буфере setjmp. Он вычисляет расположение адреса возврата для кадра LdrpInitializeThread, устанавливает его как адрес назначения последующей операции копирования и изменяет указатель InLoadOrderModuleList текущей записи модуля, разрывая цикл.

7. Перезаписать адрес возврата. После выхода из цикла в csrss.exe эксплойт выполняет ещё две операции копирования: заменяет адрес возврата указателем stack pivot и помещает рядом адрес поддельного стека. Когда LdrpInitializeThread возвращается, выполнение продолжается в ROP-цепочке.

8. Перейти в winlogon.exe. Полезная нагрузка ROP создаёт новую секцию памяти и разделяет её с winlogon.exe, другим высокопривилегированным процессом Windows, и процессом песочницы. Затем она создаёт в winlogon.exe новый поток с точкой входа внутри секции. Процесс песочницы записывает в секцию финальную стадию эксплойта, которая загружает и выполняет имплант. Остальная часть ROP-нагрузки восстанавливает нормальное состояние csrss.exe и завершает поток отчёта об ошибке.

Исправление

Мы сообщили о проблеме Microsoft 23 марта. Как и ошибки шрифтов, она подпадала под семидневный срок Project Zero для активно эксплуатируемых уязвимостей, но по просьбе поставщика мы согласились предоставить продление из-за глобальных обстоятельств, связанных с COVID-19. Исправление вышло через 22 дня после нашего отчёта.

Патч переименовал BaseSrvSxsCreateActivationContext в BaseSrvSxsCreateActivationContextFromMessage и добавил ещё один вызов CsrValidateMessageBuffer для поля ApplicationName, на этот раз с MaximumLength в качестве аргумента размера:

Приложение A

Следующий воспроизводящий пример проверен на Windows 10.0.18363.959.

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

Ошибка была простой. В первом цикле for() верхняя граница числа итераций не проверялась, поэтому данные можно было читать в массивы по адресам &values[0], &values[1], ..., а затем за границами — &values[16], &values[17] и так далее. Важнее всего, что функция GetOpenFixedArray в зависимости от входного файла может прочитать от 0 до 15 32-разрядных значений с фиксированной точкой, поэтому на определённых смещениях можно было записывать мало данных или не записывать их вовсе. Это создавало мощный примитив несмежного повреждения стека, позволявший легко перенаправить выполнение на конкретный адрес или построить ROP-цепочку прямо в стеке. Например, сама функция SetBlendDesignPositions была скомпилирована с cookie /GS, но для захвата управления можно было перезаписать другой адрес возврата выше по цепочке вызовов.

Для запуска ошибки достаточно загрузить шрифт Type 1 со специально сформированным объектом /BlendDesignPositions:

В выделенной строке сначала задаются 22 пустых массива, которые не повреждают память, а лишь увеличивают индекс до &values[22]. Затем 32-разрядные значения 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x41414141, 0xfffffff записываются в values[22][0..5]. В уязвимой Windows 8.1 это совпадает с расположением незащищённого адреса возврата выше в стеке. При загрузке такого шрифта через GDI возникает следующий kernel bugcheck:

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

Согласно нашему анализу, шрифтовый эксплойт поддерживал следующие версии Windows:

• Windows 8.1 (NT 6.3)

• Windows 8 (NT 6.2)

• Windows 7 (NT 6.1)

• Windows Vista (NT 6.0)

При запуске в системах до Windows 8 включительно эксплойт дважды вызывал условие write-what-where, ошибку №1, чтобы разместить минималистичный 8-байтовый bootstrap-код по фиксированному адресу около 0xfffff90000000000. Это место соответствует session space win32k.sys и в старых версиях Windows отображается как RWX, поэтому обход KASLR не требовался. Затем эксплойт использовал ошибку №2, чтобы перенаправить выполнение на полезную нагрузку первой стадии. Каждое действие выполнялось одним системным вызовом NtGdiAddRemoteFontToDC, который удобно загружает шрифты Type 1 из памяти, как ранее обсуждалось здесь, и позволял достичь обеих уязвимостей. Весь процесс повышения привилегий занял всего три системных вызова.

В Windows 8.1 всё сложнее, поскольку session space больше не является исполняемым:

Поэтому эту память нельзя столь же просто использовать как staging area для контролируемого кода режима ядра, однако примитив write-what-where позволяет обойти ограничение множеством способов. В данном эксплойте автор вместо session space выбрал другую страницу с постоянным адресом — область shared user data по адресу 0xfffff78000000000. По умолчанию эта страница тоже неисполняемая, но благодаря фиксированному расположению таблиц страниц в Windows 8.1 её можно сделать исполняемой одной 32-разрядной записью значения 0x0 по адресу 0xfffff6fbc0000004, где хранится соответствующая запись таблицы страниц. Именно это и сделал эксплойт: отключил бит NX в PTE, записал на общую пользовательскую страницу 192-байтовую полезную нагрузку и выполнил её. Этот путь кода также выполнял дополнительную очистку: сначала восстанавливал бит NX, а затем стирал следы атаки из памяти.

После достижения начальным shellcode выполнения в ядре следовала последовательность промежуточных этапов, каждый из которых распаковывал следующую, более длинную стадию и переходил к ней. Часть кода была закодирована в PostScript-объекте /FontMatrix, часть — в /FontBBox, а ещё больше непосредственно в данных потока шрифта. На этом этапе эксплойт разрешал адреса нескольких экспортированных символов в ntoskrnl.exe, выделял память RWX вызовом ExAllocatePoolWithTag(NonPagedPool), копировал финальную полезную нагрузку из адресного пространства пользовательского режима и выполнял её. На этом мы завершим анализ, поскольку механика shellcode ring 0 выходит за рамки публикации.

Исправления

Мы сообщили о проблемах Microsoft 17 марта. Изначально они подпадали под семидневный срок Project Zero для активно эксплуатируемых уязвимостей, но по просьбе поставщика мы согласились предоставить продление из-за глобальных обстоятельств, связанных с COVID-19. Microsoft опубликовала уведомление безопасности 23 марта, призвав пользователей применить обходные меры, например отключить шрифтовый драйвер atmfd.dll. Исправления вышли 14 апреля в составе Patch Tuesday, через 28 дней после нашего отчёта.

Поскольку обе ошибки были простыми, исправления оказались такими же. В функции ParseBlendVToHOrigin массивы ptrs и values расширили до 16 элементов и добавили sanity check, гарантирующий, что numMasters не превышает 16:

В функции SetBlendDesignPositions добавили проверку границ, ограничивающую число итераций цикла шестнадцатью:

С серверов эксплойтов мы извлекли:

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

Независимо от выбранной архитектуры передачу звука или видео с устройства ввода должен явно включить код приложения, использующий WebRTC. Обычно для этого применяется механизм tracks. Каждое устройство ввода считается «track», и для начала передачи звука или видео конкретный track необходимо добавить в конкретное одноранговое соединение вызовом addTrack или его эквивалента в соответствующем языке. Tracks также можно отключать, что удобно для реализации выключения микрофона и камеры. У каждого track есть свойство RTPSender, позволяющее точно настраивать параметры передачи и также отключать передачу звука или видео.

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

Signal Messenger

Я исследовала Signal в сентябре 2019 года. В то время схема установки звонка в приложении была очень похожа на рекомендуемую в документации WebRTC.

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

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

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

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

JioChat и Mocha

В июле 2020 года я случайно обнаружила две очень похожие уязвимости в мессенджерах JioChat и Mocha, проверяя, сработает ли в них эксплойт WebRTC. Оба использовали похожую архитектуру сигнализации через посредничество сервера.

Offer и answer передаются через сервер, после чего и вызывающая, и вызываемая стороны отправляют серверу свои candidates. Сервер хранит их, пока вызываемая сторона не примет звонок через своё устройство. Затем создаётся одноранговое соединение, а когда WebRTC переходит во внутреннее подключённое состояние, добавляется track и начинается передача звука и видео.

У этой архитектуры есть фундаментальная проблема: candidates необязательно передавать отдельно, их можно включить в SDP offer или answer. В таком случае одноранговое соединение установится немедленно, поскольку единственным препятствием для соединения в этой архитектуре является отсутствие candidates, а это, в свою очередь, приведёт к передаче данных с устройств ввода. Я проверила это с помощью Frida, добавляя candidates в offers, создаваемые каждым приложением. Мне удалось заставить JioChat передавать звук, а Mocha — передавать звук и видео. Обе уязвимости вскоре после сообщений о них исправили фильтрацией SDP на сервере.

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

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

Duo

Я исследовала Google Duo в сентябре 2020 года. Метод сигнализации Duo несколько отличается от многих мессенджеров, поскольку приложение позволяет вызываемой стороне просмотреть видео звонящего до ответа. Поэтому до принятия звонка необходимо установить односторонний видеопоток.

На изображении выше показана установка одностороннего видеопотока. Пунктирные линии обозначают асинхронные вызовы, выполненные через Java executors. Отсутствие передачи от вызываемой стороны вызывающей обеспечивается двумя методами. Во-первых, SDP offer содержит для видео свойство a=sendonly, заставляющее передавать видео только в одном направлении. Во-вторых, получив offer от вызывающей стороны, вызываемая добавляет видеодорожку в одноранговое соединение, но затем отключает её через свойство дорожки RTPSender. Звуковая дорожка не добавляется и не включается, пока пользователь не примет звонок.

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

Я проверила это, изменяя через Frida SDP, отправленный вызываемой стороной, а затем испробовала множество способов выиграть гонку. Сделать это оказалось довольно сложно: я потратила около двух недель, пытаясь достаточно замедлить вызов отключения видео, чтобы соединение успело установиться. В итоге я стала отправлять несколько offers и добавлять в них candidates. Это сокращало время подключения, поскольку сетевое соединение уже было установлено. Затем я отправляла по каналу данных однорангового соединения множество сообщений, требующих долгой обработки, чтобы замедлить отключение видеодорожки. В Duo сообщения данных обрабатываются в той же очереди потока, что и отключение видеодорожки, поэтому они заполняли необходимую для отключения видео очередь множеством других элементов и задерживали отключение дорожки.

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

Facebook Messenger

Я исследовала Facebook Messenger в октябре 2020 года. Цель оказалась довольно сложной из-за большого объёма обратной разработки. Сделаем шаг назад: у WebRTC есть привязки для нескольких языков программирования, позволяющие интегрировать его в написанные на них приложения. Большинство Android-приложений использует Java-привязки. Это заметно упрощает исследование конечных автоматов сигнализации: важные Java-функции, такие как setLocalDescription, обрабатывающая offers и answers, addRemoteIceCandidate, обрабатывающая candidates, и addTrack, добавляющая tracks в соединения, можно перехватить во Frida и журналировать для анализа. С помощью этих вызовов также сравнительно легко изменить поведение устройства атакующего.

Facebook Messenger интегрирует WebRTC не через Java-, а через C++-привязки. Более того, WebRTC статически компонуется с более крупной библиотекой (librtcR20.so, вероятно, библиотекой rsys, упомянутой в этой статье), поэтому символы вызовов привязок удаляются, что усложняет их перехват. Кроме того, перед передачей Facebook Messenger сериализует SDP в другой формат, поэтому понять работу сигнализации по наблюдению за трафиком трудно.

В конце концов я поняла, что единственный разумный способ разобраться в сигнализации Facebook Messenger — понять его сетевой протокол. К счастью, Facebook публично сообщала, что использует fbthrift, ответвление thrift. Я загрузила библиотеку librtcR20.so в IDA, чтобы найти места вызова thrift, но хотя несколько вызовов присутствовало, большая часть кода выглядела статически скомпонованной. В итоге выяснилось, что thrift генерирует код сериализации для каждого реализованного протокола, поэтому большая часть кода сериализации и десериализации компилируется вместе с кодом обработки протокола. Тогда я решила скомпилировать fbthrift, создать пример сериализатора и изучить его в IDA, чтобы понять, как выглядят скомпилированные сериализаторы fbthrift. Я заметила, что при сериализации поля объекта сериализуются вызовом метода writeFieldBegin. Также оказалось, что при вызове этого метода требуется имя поля, хотя обычно оно не входит в сериализованный вывод. Поэтому я стала искать в librtcR20 функцию, которая очень часто вызывается с разными строковыми параметрами, похожими на имена полей. Этому критерию соответствовало совсем немного функций, и мне удалось идентифицировать writeFieldBegin.

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

Ранее я заметила в библиотеке метод P2PCall::OnP2PMessageFromPeer. Его символ удалён, но имя метода записывается в журнал при вызове. Он казался вероятным местом обработки десериализованного сообщения. Поиск строки «P2PMessage» привёл меня к коду сериализации типа P2PMessageRequest. Я предположила, что именно здесь создаются сообщения установки звонка.

Код сериализации Thrift генерируется из определений классов в файле определений thrift. По именам и типам полей, передаваемым writeFieldBegin, мне удалось постепенно восстановить полное thrift-определение этого типа. Это была утомительная работа: определение оказалось довольно длинным, а код был обфусцирован так, что регистры использовались непоследовательно, поэтому я не доверяла точности какого-либо автоматизированного подхода.

Ниже приведён фрагмент кода сериализации.

Обратите внимание, что он записывает два поля объекта типа Extmap. Первое поле с именем id является обязательным. Функция, записывающая код, показана ниже.

Записываемый идентификатор поля равен 1, а тип поля — 8, что соответствует i32, то есть 32-разрядному целому. Второе поле необязательно, а регистры для его записи задаются следующим кодом.

Этот код задаёт имя поля uri, идентификатор поля 2 и тип поля 8, также i32. В совокупности код можно представить следующим thrift-определением.

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

Я использовала это thrift-определение для двух задач. Во-первых, с его помощью я определила расположение типа P2PMessageRequest в C++. Это было чрезвычайно полезно, поскольку позволило загрузить в IDA определение структуры с правильными именами абсолютно всех полей. Так стало гораздо проще понять обработку входящих сообщений в P2PCall::OnP2PMessageFromPeer. Для этого потребовалось несколько шагов. fbthrift умеет создавать заголовочные файлы C++ непосредственно из thrift-определения, но они очень длинные, содержат множество ненужных определений и не обрабатываются IDA. Поэтому я скомпилировала созданный исходный код, загрузила его в IDA, экспортировала определения структур и импортировала их в другой экземпляр IDA с уже загруженной librtcR20.so. Размер нескольких полей в моей сборке отличался от сборки Facebook, но сходство было достаточным, чтобы всё заработало после нескольких изменений.

Ниже приведён пример декомпилированного в IDA кода с импортированным thrift-определением. Он показывает, насколько проще становится понимать обработку объекта сообщения.

Я также смогла декодировать и создавать сообщения, передаваемые по сети. Для этого из thrift-определения я сгенерировала код сериализации на Python, поскольку thrift поддерживает генерацию кода для многих языков. Затем этот код можно было импортировать при использовании Frida Python для перехвата функций Facebook Messenger.

Далее требовалось найти код обработки входящих сообщений P2PMessageRequest. Эти сообщения обрабатываются машинным кодом, тогда как большинство сообщений Facebook обрабатывает Java-код, поэтому я искала машинный вызов с подходящим именем. Им оказался com.facebook.webrtc.WebrtcEngine.onThriftMessageFromPeer. Я перехватила этот метод с помощью Frida, передала его параметр-массив байтов сгенерированному десериализатору, и тот декодировал входящие сообщения.

Я нашла похожий метод для отправки thrift-сообщений — sendThriftToPeer. Имя класса этого метода обфусцировано и меняется в каждой версии Facebook Messenger, но его можно найти поиском по smali приложения. Мне также удалось перехватить этот метод и изменить его параметр-массив байтов, чтобы модифицировать отправляемое Facebook Messenger сообщение P2PMessageRequest.

Теперь я могла понять конечный автомат сигнализации Facebook Messenger. Сигнализация может работать двумя способами в зависимости от того, где пользователь вошёл в Facebook Messenger. Если вход выполнен на нескольких устройствах или в нескольких браузерах, до взаимодействия вызываемой стороны со своим устройством почти ничего не происходит. Offer, answer и candidates передаются, но устройство вызываемой стороны сохраняет их и не обрабатывает до ответа пользователя на звонок. Это логично, поскольку иначе Facebook Messenger не знает, с каким устройством устанавливать соединение.

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

В этом случае Facebook Messenger включает track сразу после получения offer, но изменяет offer так, чтобы все исходящие потоки были неактивны. После взаимодействия пользователя с устройством приложение заменяет offer вариантом с активными потоками.

Я опасалась, что изменение offer можно каким-то образом обойти, но изучила его реализацию, и хотя обычно не рекомендую отключать передачу с устройств ввода каким-либо способом, кроме добавления или отключения tracks, она оказалась довольно надёжной. Offer изменяется после декодирования SDP во внутренний объект WebRTC, причём изменения вносятся непосредственно в этот объект, что исключает возможность ошибок разбора.

Однако при изучении обработки входящих сообщений я заметила, что до ответа на звонок обрабатывается множество типов сообщений помимо offers, answers и candidates. Особенно выделялся тип SdpUpdate. При получении сообщения SdpUpdate локальный offer или answer обновлялся вызовом setLocalDescription.

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

Неясно, для чего тип сообщения SdpUpdate используется в Facebook Messenger. Я испробовала на тестовых устройствах множество сценариев, включая переключение сети, но при нормальной работе такое сообщение создать не удалось. Тем не менее очевидно, что получать сообщения этого типа до ответа на звонок не предполагалось. Ошибка похожа на описанную выше ошибку Signal: она связана не с использованием WebRTC приложением, а с отсутствующей проверкой при обработке входных данных, способных вызвать переход состояния.

Эту уязвимость исправили в ноябре 2020 года изменениями на сервере, запрещающими отправлять сообщения этого типа до установления соединения звонка.

Другие приложения

Я исследовала ещё несколько приложений, но не нашла проблем в их конечных автоматах. Telegram был проверен в августе 2020 года, сразу после добавления видеоконференций. Проблем обнаружить не удалось главным образом потому, что приложение не передаёт offer, answer или candidates, пока вызываемая сторона не ответит на звонок. В ноябре 2020 года я исследовала Viber и также не нашла проблем в его конечном автомате, хотя сложности обратной разработки приложения сделали этот анализ менее строгим, чем анализ других приложений.

Обсуждение

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

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

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

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

Заключение

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