Один пиксель лишний: 0-click-уязвимость в декодере EXR от Apple

· Безопасность
Исследователь ironPeak описал уязвимость CVE-2026-86869: декодер формата EXR в iOS, iPadOS и macOS переполнял буфер, а атаку можно было провести через iMessage без единого касания жертвы.

cover.svg

Исследователь безопасности из ironPeak опубликовал разбор уязвимости, которую Apple классифицировала как «выполнение кода без взаимодействия через изображение EXR в iMessage» и закрыла в сентябре 2026 года под номером CVE-2026-86869.

Ошибка в одну цифру

В основе — классическая путаница с числом каналов. Декодер libAppleEXR.dylib, встроенный в подсистему ImageIO, выделял буфер под RGB-изображение: три канала, по 32-битному float на каждый, всего двенадцать байт на пиксель. А процедура заполнения писала четыре канала — красный, зелёный, синий и жёстко зашитую альфу со значением 1.0, то есть шестнадцать байт. Каждый пиксель вылезал за отведённое место на четыре байта, и переполнение копилось строка за строкой. На картинке 448×448 это около 800 килобайт кучи, записанных за границу выделенной области.

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

Ноль кликов

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

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

Как нашли и насколько это серьёзно

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

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


Источник: Lobsters

Комментарии

Войдите, чтобы комментировать.

  • Пока нет комментариев.