Уязвимость в Android-прошивке, позволяющая выполнить код через отправку сообщения, стала наглядным примером того, как интеграция ИИ-сервисов в мобильные ОС расширяет поверхность атаки и превращает раньше «полубезопасные» мультимедийные вложения в полноценный вектор взлома.
Исследователи из команды Google Project Zero детально разобрали цепочку эксплуатации, которая позволяет удалённому злоумышленнику выполнить произвольный код с правами ядра Linux, просто отправив жертве SMS- или RCS-сообщение со специально подготовленным аудиофайлом. Пользователь при этом не обязан открывать, прослушивать или даже замечать сообщение — атака относится к классу 0-click, то есть не требует никаких действий со стороны владельца устройства.
В рабочем эксплоите объединены две уязвимости: ошибка в библиотеке Dolby Unified Decoder (идентификатор CVE-2025-54957) и уязвимость в драйвере ядра Linux bigwave (CVE-2025-36934). Ранее подобные проблемы в медиа-кодеках чаще всего можно было использовать только при условии, что пользователь вручную откроет файл, запустит воспроизведение или просмотр. Однако архитектура современных прошивок изменилась: AI-функции автоматом обрабатывают и анализируют медиа сразу после получения, что превращает пассивный медиаконтент в триггер удалённого нападения.
Ключевой элемент цепочки — поведение приложения Google Messages. Для звуковых SMS- и RCS-сообщений оно автоматически инициирует работу сервиса com.google.android.tts, который создаёт текстовую транскрипцию аудио. Эта транскрипция затем используется для поиска по содержимому голосовых сообщений. Важный момент: декодирование аудио запускается автоматически по факту доставки сообщения, и пользователь никак это не подтверждает. В результате уязвимый аудиокодек получает на вход специально сформированный вредоносный аудиопоток, и эксплойт срабатывает в полностью автоматическом режиме.
Проблема в Dolby Unified Decoder связана с целочисленным переполнением при вычислении размера буфера, выделяемого под структуры syncframe. Ошибка в расчёте позволяет выделить недостаточно памяти и, как следствие, записать данные за пределы буфера. Это приводит к повреждению критически важных указателей. В описанном исследователями сценарии удаётся перезаписать указатель, который участвует в обработке следующего синхронизирующего кадра. Манипулируя содержимым этого кадра, атакующий получает возможность изменить указатель на функцию и передать управление собственному коду — уже в контексте процесса с правами "mediacodec", ограниченного политиками SELinux, но всё же обладающего заметными возможностями.
Далее в ход идёт вторая уязвимость — в драйвере bigwave, обслуживающем символьное устройство /dev/bigwave. Доступ к этому устройству открыт из SELinux-контекста "mediacodec", что и позволяет продолжить атаку. Уязвимость в драйвере связана с некорректной обработкой ioctl-вызова BIGO_IOCX_PROCESS: злоумышленник может организовать перезапись структур данных в пространстве ядра. При грамотно подобранных параметрах это даёт возможность повысить привилегии и добраться до исполнения кода уже с правами ядра Linux, фактически захватывая полный контроль над устройством.
Важно, что проблема в Dolby Unified Decoder (библиотека libcodec2_soft_ddpdec.so, отвечающая за декодирование форматов Dolby Digital — DD, AC-3 и Dolby Digital Plus — DD+, EAC-3) не является специфичной для Android или Pixel 9. Та же уязвимость проявлялась на целой линейке платформ, включая современные смартфоны и ноутбуки разных производителей, а также десктопные и ноутбучные ОС. Это подчёркивает системный характер проблемы: уязвим не конкретный телефон, а общий программный компонент аудиодекодирования, встроенный в разные экосистемы.
При этом меры защиты в разных системах заметно отличаются. В AOSP и в прошивке для некоторых Android-устройств, включая Samsung S24, для процессов в контексте mediacodec применяется seccomp-фильтр системных вызовов. Такой фильтр жёстко ограничивает доступный набор системных вызовов, тем самым усложняя или вовсе блокируя дальнейшую эксплуатацию ошибок в ядре. В прошивке Pixel 9 аналогичной защиты не было, что и позволило выстроить полноценную цепочку от уязвимого декодера до кода в ядре.
От подобного класса атак мог бы эффективно защитить аппаратный механизм Memory Tagging Extension (MTE), который помогает выявлять и блокировать эксплуатацию ошибок, связанных с обращением к памяти (выход за границы буфера, use-after-free и подобные). Однако на устройствах Pixel 8 и новее MTE доступен лишь как опция, активируемая при включении режима усиленной защиты (Advanced Protection), а по умолчанию он не задействован. Получается, даже там, где аппаратные механизмы уже есть, они нередко остаются выключенными ради совместимости и производительности.
На платформах macOS и iOS эксплуатацию уязвимости затрудняет другой подход: библиотека Dolby Unified Decoder компилируется с использованием флага компилятора, добавляющего дополнительные проверки выхода за границы массивов. Это снижает производительность, но увеличивает шансы на обнаружение попытки эксплуатации (и на её срыв). В итоге один и тот же программный компонент в разных экосистемах оказывается по-разному защищён — кто-то жертвует скоростью ради безопасности, а кто-то, наоборот, оставляет пространство для атак ради максимальной производительности.
Особое внимание исследователи уделили не только технической стороне, но и тому, как долго исправление уязвимости добиралось до конечных пользователей. Хронология выглядит показательно. О проблеме Dolby Unified Decoder компания Dolby была уведомлена 26 июня 2025 года. Уже 18 сентября вышло первое бинарное исправление для одной из платформ, но для Android-устройств соответствующие патчи Dolby предоставила лишь 8 октября. 15 октября информация об уязвимости стала публичной, то есть с этого момента потенциальные злоумышленники могли изучить детали и попытаться воспроизвести эксплойт. Samsung выпустила свои исправления 12 ноября, а пользователи Pixel дождались патча только 5 января. В сумме распространение исправления до всей значимой части Android-экосистемы заняло 139 дней.
При этом сама уязвимость в Dolby Unified Decoder была обнаружена менее чем за двое суток анализа кода. Ошибка в драйвере bigwave была найдена ещё быстрее — меньше чем за день рецензирования. На разработку рабочего эксплоита для Dolby Unified Decoder один исследователь потратил примерно восемь недель, а на эксплуатацию BigWave — около трёх. То есть соотношение «время поиска и разработки эксплоита» и «время доставки исправления пользователям» оказалось весьма неблагоприятным для последних: атакующий, располагающий нужной квалификацией, мог уложиться в несколько недель, тогда как обычные пользователи оставались незащищёнными многие месяцы.
Дополнительный диссонанс вызывает оценка опасности уязвимостей. В отчёте Dolby от 14 октября ошибка в Dolby Unified Decoder была формально помечена как малозначимая, хотя к этому моменту разработчики уже имели детальные сведения о том, что на её основе создаётся практический эксплойт для удалённого выполнения кода. Уязвимости в драйвере BigWave в Android первоначально присвоили лишь средний уровень опасности (Moderate), мотивацией служило то, что атака якобы возможна только из привилегированного контекста и недоступна обычным приложениям. Лишь спустя несколько месяцев статус был пересмотрен и поднят до «опасной проблемы». Такая недооценка на раннем этапе фактически замедляет реакции разработчиков и производителей, откладывая приоритетное внедрение патчей.
Отдельная проблема — судьба старых устройств. Да, крупные вендоры в итоге выпускают обновления для флагманов и относительно свежих моделей. Но что происходит с аппаратом, купленным, скажем, пять лет назад, который формально продолжает работать исправно? Большая часть таких устройств давно не получает регулярных обновлений прошивки. Даже если уязвимый компонент Dolby используется и там, патч может так и не добраться до конечных пользователей. В результате значительная доля парка активных устройств остаётся потенциально уязвимой ещё дольше, чем новейшие модели.
На фоне активной интеграции ИИ-ассистентов, автоматической транскрипции, распознавания речи и «умной» обработки медиа каждая новая функция, упрощающая жизнь пользователю, одновременно увеличивает и набор сценариев для атакующего. Там, где раньше нужно было «заставить» пользователя открыть файл, сегодня достаточно заставить систему автоматически его проанализировать. И пока производители стремятся сделать интерфейсы более удобными и «умными», вопросы безопасности иногда оказываются вторичными или же упираются в сложные компромиссы.
Практическая мораль из этой истории неоднозначна. С одной стороны, полное отказ от использования ИИ-функций в современных смартфонах малореалистичен — они всё глубже интегрируются в саму ОС и стандартные приложения. С другой — пользователям стоит внимательнее относиться к настройкам конфиденциальности и безопасности, по возможности отключая не критичные для себя автоматические функции обработки медиа и включая доступные режимы усиленной защиты, вроде тех же опций наподобие Advanced Protection и аппаратных механизмов защиты памяти, если они присутствуют.
Производителям же очевидно необходимо:
1. Жёстче внедрять принципы безопасной разработки библиотек и драйверов, особенно тех, что отвечают за автоматическую обработку внешних данных.
2. По умолчанию активировать защитные механизмы, вроде seccomp-фильтров и MTE, хотя бы на устройствах, ориентированных на корпоративный сегмент и категории повышенных рисков.
3. Ускорять цепочку доставки патчей от поставщика библиотек до конечного пользователя, сокращая месяцы до недель.
4. Пересмотреть подход к оценке опасности уязвимостей, особенно когда речь идёт о компонентах, обрабатывающих сетевой или мультимедийный контент без действий пользователя.
Наконец, пользователям стоит понимать: даже если компаниям удаётся находить уязвимости и формально выпускать исправления, само по себе это не гарантирует мгновенную безопасность. Между обнаружением ошибки и фактическим получением патча на конкретное устройство может пройти несколько месяцев, а для старых аппаратов — патч может не прийти никогда. В такой реальности единственной устойчивой стратегией остаётся сочетание технических средств защиты, разумных пользовательских настроек и осознанного отношения к тому, какие функции автоматической обработки контента действительно нужны, а какие стоит отключить, даже если они предлагают «умный» сервис и удобство.
