Анализ:

Функции ZinComputeProgramGetNamesFromMultiPlaneLinear() и ZinComputeProgramGetNamesFromMultiPlaneTiledCompressed() отвечают за разбор входных и выходных данных процедуры, а точнее — за команду LC_THREAD с flavor потока 2 (ane_bind_state), у которой значение binding_type_info равно 4 и 5.

Насколько я могу судить, binding_type_info = 4 означает, что вход процедуры содержит более одного плана (plane), а binding_type_info = 5 означает, что вход не только содержит более одного плана, но и сжат.

Функция ZinComputeProgramGetNamesFromMultiPlaneLinear(), например, принимает 5 аргументов: указатель на load command, указатель на thread binding и три дополнительных выходных аргумента. Последний выходной аргумент planes — это массив, который будет содержать планы (или указатели ядра), чьё содержимое контролируется пользователем, а последний аргумент planeCount указывает, сколько планов (или указателей ядра) было скопировано в planes из файла model.hwx. Ниже приведено определение функции:

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

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

Массив planes — это стековая переменная, расположенная в H11ANEIn::ANE_ProgramCreate_gated(), и при переполнении этой переменной (которая должна содержать несколько планов, до 4 элементов) более чем 4 планами могут быть повреждены и другие стековые переменные, что может привести к другим проблемам, таким как путаница типов (type confusion), поскольку перезаписываемые указатели ядра полностью контролируются пользователем.

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

Превращение повреждения памяти в переполнение кучи:

Ещё один интересный сценарий, как показано на изображении ниже, — возможность переполнить два heap-объекта: H11ANEProgramBindingInfo (строка 528) и H11ANEProgramCreateArgsStructOutput (строка 533).

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

Запуск уязвимости:

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

Как вы, возможно, знаете, чтобы загрузить модель через aned, модель должна быть скомпилирована системным сервисом ANECompilerService или подписана Apple. Другими словами, приложение должно предоставить aned каталог .mlmodelc, который затем запросит у ANECompilerService компиляцию в model.hwx с использованием двух фреймворков: Espresso и ANECompiler. Если вы не знаете, о чём я говорю, можете взглянуть на слайды #POC2022 здесь, где я дал базовый обзор того, как работает aned. Кроме того, более подробно о процессе компиляции можно узнать в отличном выступлении на BlackHat Wish Wu о его исследовании ANE, а также в его замечательном инструменте, который в точности имитирует то, что делает ANECompilerService.

В нашем случае нам нужен model.hwx с процедурой, чей вход (или выход) поддерживает несколько планов. К сожалению, такой модели нет в форматах mlmodel, mlmodelc или mlpackage, и лишь несколько моделей в формате hwx предоставлены Apple. Анализ этих hwx-моделей показал, что они используют какие-то странные/недокументированные операции нейронных сетей, которые не существуют в кодовой базе открытой библиотеки coremltools, что намекает на то, что эти сетевые слои, вероятно, предназначены только для внутреннего использования. Однако реализация этих операций определяется фреймворком Espresso, и требуется некоторый реверс-инжиниринг, чтобы понять, какие входы и выходы они поддерживают и как правильно использовать их в качестве слоя внутри нейронной сети. Поскольку фреймворк написан на C++ со STL, мне было неинтересно реверсить эту операцию, потому что это заняло бы вечность.

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

Поэтому я взял простой model.hwx и пропатчил одну из его команд LC_THREAD, чтобы воспроизвести желаемый результат в ane_bind_state, а затем использовал CVE-2022-32845, чтобы обманом заставить aned загрузить его так, как будто он подписан Apple; этого было достаточно, чтобы продемонстрировать уязвимость в Apple.

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

Патч:

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

На этом всё, скоро увидимся!