По неподтверждённым публикациям, Project Zero портировал полную 0-click цепочку с Pixel 9 на Pixel 10 менее чем за сутки. Пусть это осядет: менее чем за сутки. Адаптация эксплойта CVE-2025-54957 для Tensor G5 предположительно потребовала обхода RET PAC - Pointer Authentication Codes заменили классические stack canaries, и привычный перехват
__stack_chk_fail перестал работать. Решение, по неподтверждённым данным, нашлось через перезапись инициализационной функции dap_cpdp_init, которая вызывается ровно один раз при старте декодера и потом просто лежит мёртвым грузом в памяти. Но по-настоящему показательна - если описание верно - вторая часть цепочки. Вместо закрытого драйвера BigWave на Pixel 10 предположительно обнаружился VPU-драйвер с уязвимостью, для эксплуатации которой хватило пяти строк кода: произвольное чтение-запись всей физической памяти устройства, включая .text и .data ядра, без какого-либо обхода ASLR. Физический адрес ядра на этом устройстве, по имеющимся данным, фиксирован. Просто захардкожен. В 2025 году. На флагмане Google.Для атакующего ценность такой цепочки - полный компромисс устройства без единого тапа жертвы. Достаточно знать номер телефона и отправить SMS или RCS с crafted аудиовложением. Результат - root-доступ к ядру с возможностью чтения переписок, перехвата криптографических ключей, активации микрофона. По данным CISA Vulnrichment, атака автоматизируема (
automatable: yes) с полным техническим импактом (technical impact: total). При этом на момент публикации CISA фиксирует exploitation: none - в дикой природе пока не замечена.Цепочка эксплойтов Android: от входящего SMS до kernel root
Вся цепочка укладывается в два эксплойта и три этапа. Для mobile exploit chain - необычно компактно.Этап 1 - Initial Access и Execution (T1203, Exploitation for Client Execution). Атакующий отправляет SMS или RCS-сообщение со звуковым вложением в формате Dolby Digital Plus (EAC-3). Google Messages автоматически передаёт входящие аудиовложения на транскрипцию - сервис
com.google.android.tts декодирует аудио без какого-либо взаимодействия пользователя. Этот механизм появился с интеграцией AI-помощников в последних версиях Android и превратил аудиокодеки в полноценную 0-click поверхность атаки. До автотранскрипции эксплуатация кодеков требовала, чтобы жертва открыла и прослушала вредоносный файл. Теперь - нет.Этап 2 - Code Execution в mediacodec. Malformed DD+ bitstream триггерит CVE-2025-54957 в библиотеке Dolby Unified Decoder (
libcodec2_soft_ddpdec.so). Integer overflow при расчёте размера аллокации в evo heap приводит к out-of-bounds write (CWE-787) с контролируемым содержимым и размером перезаписи. Атакующий получает выполнение произвольного кода в SELinux-контексте mediacodec - песочнице для программных декодеров.Этап 3 - Privilege Escalation (T1068, Exploitation for Privilege Escalation). Из контекста
mediacodec атакующий обращается к драйверу VPU (/dev/vpu), доступному через SELinux-политику. Уязвимый mmap-хендлер позволяет маппировать произвольный объём физической памяти в userspace, включая всю область ядра. Перезапись любой функции ядра даёт root.Что должно быть выполнено до: отправка crafted аудиофайла, доставка через SMS/RCS-канал, автоматический запуск декодирования Google Messages. Что следует после: произвольное выполнение кода на уровне ядра, установка бэкдора, извлечение данных.
Анатомия CVE-2025-54957: integer overflow в Dolby UDC
CVE-2025-54957 затрагивает Dolby Unified Decoder (UDC) версий 4.5 - 4.13. По данным NVD - CVSS 9.8 (CRITICAL) с векторомAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: сетевой вектор, низкая сложность, ни привилегий, ни взаимодействия пользователя. Классификация по CWE: CWE-190 (Integer Overflow or Wraparound) и CWE-787 (Out-of-bounds Write). Обе отражают разные стороны одного дефекта - integer overflow приводит к некорректному расчёту размера буфера, после чего запись данных выходит за его границы.Dolby UDC - проприетарная библиотека, поставляемая OEM-производителям в виде бинарного блоба с минимальной символьной информацией. На Pixel 9/10 она статически слинкована в
/vendor/lib64/libcodec2_soft_ddpdec.so. Уязвимость не специфична для Android - тот же бинарь интегрирован в iOS, macOS, Windows (MSRC оценивает уязвимость на Windows как Important, CVSS 7.0, с классификацией CWE-190 и CWE-502, тогда как NVD указывает CWE-190 и CWE-787 при CVSS 9.8 CRITICAL - integer overflow совпадает, а описание последствий расходится), ChromeOS и потоковые устройства.Архитектура evo heap и обработка EMDF
DD+ аудио обрабатывается из bitstream, состоящего из независимо декодируемых syncframes. Каждый syncframe содержит до шести audio blocks, в каждом - полеskipl (длина данных, копируемых в skip buffer). Максимальный размер одного копирования - 0x1FF байт, суммарно до 0x1FF * 6 = 0xBFA байт на syncframe.Содержимое skip buffer интерпретируется как данные в формате Extensible Metadata Delivery Format (EMDF). Декодер ищет syncword
0xE8 и далее разбирает EMDF-контейнер, включающий emdf_payload_size - размер полезной нагрузки, вычисляемый через функцию variable_bits. Спецификация не ограничивает значение emdf_payload_size, а variable_bits может вернуть произвольно большое число. Вот тут и начинается веселье.Evo heap - простейший bump-аллокатор: один slab памяти с указателем текущей позиции. Память выделяется инкрементом указателя, освобождение отдельных блоков невозможно. Весь heap сбрасывается после обработки каждого syncframe - данные между фреймами не сохраняются. Этот минимализм критичен для понимания эксплойта: у аллокатора нет metadata (заголовков чанков, free lists), что делает heap corruption детерминированной. Никаких гаданий с heap feng shui - всё предсказуемо.
Integer wraparound в evo_malloc
Функцияddp_udc_int_evo_malloc выполняет аллокацию на evo heap. Ниже - реконструированный псевдокод, адаптированный из анализа Project Zero (не оригинальный код; арифметика упрощена для иллюстрации):
C:
// ddp_udc_int_evo_malloc - аллокатор evo heap (реконструкция из P0)
total_size = alloc_size + extra;
if (alloc_size + extra < alloc_size)
return 0; // проверка переполнения суммы - тут всё корректно
if (total_size % 8)
total_size += (8 - total_size) % total_size; // BUG: integer wraparound
if (total_size > heap->remaining)
return 0;
mem = heap->curr_mem;
heap->remaining -= total_size;
heap->curr_mem += total_size;alloc_size + extra на переполнение сделана правильно. Проблема - в выравнивании до границы 8 байт. Выражение (8 - total_size) % total_size при total_size близком к SIZE_MAX (на 64-битной платформе) может дать неожиданно малый результат. После сложения total_size wrap-ается в маленькое значение - и проверка total_size > heap->remaining пропускает аллокацию. При total_size == 0 выражение вызывает деление на ноль (undefined behavior в C). Реальный уязвимый код может отличаться в деталях арифметики. Результат: буфер выделяется размером в единицы байт, а запись в него идёт по оригинальному payload_length, который может составлять сотни байт.Два свойства делают этот баг подарком для эксплуатации:
Первое - контролируемый размер перезаписи. Каждый байт, записываемый в буфер, читается из skip buffer через
ddp_udc_int_evo_brw_read, которая проверяет границы чтения по emdf_container_length. Исчерпались данные - цикл записи прерывается. Атакующий контролирует emdf_container_length через bitstream, задавая точное количество байт за пределами буфера.Второе - информационная утечка. Когда
emdf_container_length превышает реальную длину данных в skip buffer (skipl), декодер читает за пределами skip buffer. Готовый примитив чтения (information leak) для обхода ASLR в userspace-процессе.Комбинация контролируемого OOB write + information leak - полноценный exploit primitive. На Pixel 9 Project Zero использовал перезапись поля
payload_extra в структуре EMDF и подмену указателя на функцию для перехвата управления. Перезаписанный указатель срабатывал - и выполнялся код атакующего. Надёжность эксплойта, по оценке Project Zero, была достаточной для боевого применения.Обход патча CVE-2025-54957 при портировании на Pixel 10
больше никогда не вызывается - перезапись её кодового региона контролируемыми данными не ломает работу декодера. Область памяти
dap_cpdp_init превращается в хранилище для shellcode или ROP gadgets, а указатель на вызываемую функцию (через перезапись payload_extra или аналогичной структуры) перенаправляется туда.Остальная адаптация - пересчёт офсетов для конкретной версии
libcodec2_soft_ddpdec.so на Pixel 10. Адреса функций и структур в бинарном блобе отличаются между версиями библиотеки на разных устройствах. По признанию исследователей, главной сложностью оказалась не архитектурная - а недостаточная документация того, какие syncframes в эксплойте содержат device-specific офсеты. То есть основная проблема была навигационная, не техническая.Предусловия и ограничения эксплойта Dolby UDC
Работает если:- Устройство использует Dolby UDC версий 4.5 - 4.13 (подавляющее большинство Android-устройств)
- Security Patch Level - декабрь 2025 или ранее
- Google Messages с включённой автотранскрипцией (дефолт на Pixel)
- Процесс
com.google.android.ttsавтоматически декодирует входящие аудио
- SPL январь 2026+ (патч CVE-2025-54957 применён)
- К
mediacodecприменён seccomp-фильтр системных вызовов (Samsung S24, AOSP имеют фильтр; Pixel 9 и Pixel 10 до патча - нет) - Активирован MTE (Memory Tagging Extension) - доступен на Pixel 8+ через режим "Advanced Protection", но по умолчанию отключён
- Библиотека собрана с
-fbounds-safety(macOS/iOS), что добавляет runtime-проверки границ массивов
Новый вектор атаки Pixel 10: уязвимость VPU-драйвера
CVE-2025-36934 - подтверждённая уязвимость в драйвере BigWave (/dev/bigwave), use-after-free из-за race condition (CWE-362, CWE-416), CVSS 7.4 (HIGH), вектор AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. BigWave управлял аппаратным ускорителем на Tensor G4. В рассматриваемом гипотетическом сценарии эта уязвимость предположительно использовалась как второе звено цепочки на Pixel 9 для privilege escalation из mediacodec в ядро - однако её включение в конкретную exploit-цепочку Project Zero не подтверждено официально.На Pixel 10 драйвер BigWave отсутствует - Tensor G5 использует другой аппаратный стек. Вместо BigWave появилось устройство
/dev/vpu - драйвер для чипа Chips&Media Wave677DV, отвечающего за аппаратное декодирование видео. SELinux-политика Pixel 10 предоставляет контексту mediacodec доступ к /dev/vpu. [Связь между CVE-2025-36934 и VPU-уязвимостью как звеньями одной exploit chain - часть неподтверждённого сценария.]По неподтверждённым данным, приписываемым Project Zero, драйвер VPU предположительно написан той же командой, что создала BigWave. Аудит, по этим данным, занял два часа. Результат описывается как "Holy Grail of Kernel Vulnerabilities". [Официальный отчёт Project Zero, подтверждающий эти детали, не обнаружен.]
remap_pfn_range без проверки размера - прямой доступ к памяти ядра
В отличие от upstream Linux-драйвера для более старого чипа WAVE521C, который интегрируется с V4L2 (Video for Linux API), драйвер Pixel для WAVE677DV напрямую экспонирует аппаратный интерфейс чипа в userspace - включая возможность маппирования MMIO-регистров. Вот уязвимыйmmap-хендлер:
C:
static int vpu_mmap(struct file *fp, struct vm_area_struct *vm) {
unsigned long pfn;
struct vpu_core *core =
container_of(fp->f_inode->i_cdev, struct vpu_core, cdev);
vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
vm->vm_page_prot = pgprot_device(vm->vm_page_prot);
pfn = core->paddr >> PAGE_SHIFT;
// размер маппинга = vm->vm_end - vm->vm_start - контролируется userspace
return remap_pfn_range(vm, vm->vm_start, pfn,
vm->vm_end - vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0;
}core->paddr, адрес регистрового региона VPU-чипа. А вот размер маппируемой области вычисляется как vm->vm_end - vm->vm_start - значение, полностью контролируемое из userspace через аргумент length системного вызова mmap. Проверки, что запрошенный размер не превышает реальный размер регистрового региона, - нет. Вообще.Последствия: вызов
mmap с произвольно большим length маппирует в userspace физическую память, начиная с адреса VPU-регистров и далее на указанный размер. Образ ядра Linux (секции .text, .data, .bss) располагается по более высокому физическому адресу, чем VPU-регион - и полностью попадает в маппируемый диапазон.Ядро на этом устройстве, согласно анализу, загружается по фиксированному физическому адресу. KASLR рандомизирует виртуальные адреса, но физическое расположение на конкретной модели детерминировано. Смещение между началом VPU-региона и ядром - известная константа. Атакующему не нужно ни сканировать память, ни обходить рандомизацию: зная размер VMA, он точно знает, по какому виртуальному смещению от возвращённого
mmap адреса находится каждая функция ядра. Это как если бы банк повесил табличку с расположением сейфа и выложил план здания.По неподтверждённой оценке, приписываемой Project Zero, достижение произвольного чтения-записи ядра через эту уязвимость потребовало пяти строк кода. Написание полного эксплойта - предположительно менее одного рабочего дня. Для сравнения: эксплойт Dolby UDC оценивается в 8 человеко-недель, BigWave - в 3 недели. [Эти оценки трудозатрат не подтверждены официально.]
Предусловия и ограничения VPU-эксплойта
Работает если:- Pixel 10 с Tensor G5 (Wave677DV silicon)
- Процесс имеет доступ к
/dev/vpuчерез SELinux (контекстmediacodec) - SPL до февраля 2026 (предположительно патч в February Pixel Security Bulletin - не подтверждено)
- Другие Android-устройства (BigWave/VPU - Pixel-specific драйверы)
- SPL февраль 2026+ (уязвимость закрыта)
- Устройства без Tensor G5 (другая SoC - другие драйверы, другая поверхность атаки)
- Seccomp-фильтр
mediacodecблокируетmmapсMAP_SHAREDна device files - но на Pixel 10 такой фильтр кmediacodecне применялся
Митигации: MTE, seccomp, PAC - что сработало и что нет
Цепочка для Pixel 10 показывает неоднородную эффективность защитных механизмов Android. Если коротко - почти все они на бумаге выглядят солидно, а на практике оказались либо выключены, либо обходимы.Memory Tagging Extension (MTE) - единственная митигация, способная полностью заблокировать эксплуатацию CVE-2025-54957 на аппаратном уровне. MTE маркирует каждую аллокацию 4-битным тегом и проверяет теги при каждом обращении к памяти - OOB write в соседний аллокатор с несовпадающим тегом вызывает синхронное исключение. На Pixel 8+ MTE доступен, но активируется только вручную через "Advanced Protection". По умолчанию выключен. По умолчанию не защищает.
Seccomp-фильтр для mediacodec - ограничивает набор системных вызовов из песочницы декодера. В AOSP и прошивке Samsung S24 фильтр применяется к
mediacodec, что блокирует ioctl-вызовы к BigWave и потенциально mmap-вызовы к VPU. На Pixel 9 и Pixel 10 (до момента исправления) seccomp-фильтр к mediacodec не применялся. Песочница оказалась дырявой - атакующий из mediacodec имел свободный доступ к device drivers, к которым SELinux разрешает обращение.RET PAC (Pointer Authentication) - усложнил адаптацию userspace-эксплойта, устранив
__stack_chk_fail как цель перезаписи. Но не заблокировал эксплуатацию: замена на dap_cpdp_init потребовала проб и ошибок, но не фундаментальных изменений в подходе. PAC защищает указатели возврата, но не препятствует перезаписи произвольных данных и кодовых регионов - ограничение, заложенное в дизайн.SELinux - ограничивает доступ
mediacodec к файловой системе и сетевым ресурсам, но явно разрешает обращение к /dev/vpu (и ранее к /dev/bigwave). SELinux не защищает от privilege escalation через аппаратные драйверы, если сам драйвер содержит уязвимость.KASLR - рандомизирует виртуальные адреса ядра, но физический адрес на этом устройстве фиксирован. Для VPU-эксплойта KASLR полностью нерелевантен - доступ к ядру идёт через физическую память.
| Митигация | Блокирует Dolby UDC exploit | Блокирует VPU exploit | Статус на Pixel 10 |
|---|---|---|---|
| MTE | Да | Частично (heap corruption) | Выключен по умолчанию |
| Seccomp на mediacodec | Нет (userspace exploit) | Да (блокирует mmap) | Отсутствует |
| RET PAC | Нет (обходится через dap_cpdp_init) | Не препятствует (эксплойт через mmap не подделывает return-адреса) | Включён |
| SELinux | Частично (ограничивает sandbox) | Нет (VPU разрешён) | Активен |
| KASLR | Частично (userspace ASLR) | Нет (физ. адрес фиксирован) | Активен |
| -fbounds-safety | Да | Нерелевантен | Не используется на Android |
Флаг
-fbounds-safety, применяемый Apple при сборке Dolby UDC для macOS и iOS, подставляет runtime-проверки границ массивов. Эффективно блокирует OOB write, но снижает производительность - и не используется в Android-экосистеме.Хронология патчей и Project Zero эксплойт для Pixel 10
Хронология раскрытия и исправления CVE-2025-54957 - наглядная иллюстрация системных проблем с patch pipeline в Android:- 26 июня 2025 - Dolby информирована об уязвимости
- 18 сентября 2025 - первый бинарный патч (ChromeOS)
- 8 октября 2025 - Dolby предоставляет бинарные патчи для Android
- 15 октября 2025 - публичное раскрытие уязвимости
- 12 ноября 2025 - Samsung публикует исправление
- 5 января 2026 - Google публикует исправление для Pixel
VPU-уязвимость, по неподтверждённым данным, показала улучшение: баг предположительно репортирован 24 ноября 2025, Android VRP предположительно присвоил ему severity High (улучшение по сравнению с первоначальным Moderate для BigWave), патч предположительно выпущен через 71 день. CVE-идентификатор для этой уязвимости публично не известен, детали не подтверждены официальными бюллетенями.
Вместе с тем VPU-уязвимость, по неподтверждённым данным, обнаружена через 5 месяцев после репорта BigWave - и предположительно оказалась тривиальнее предшественника. Источник, приписываемый Project Zero, указывает: после репорта BigWave ожидалось, что разработчики проведут аудит остальных драйверов - но этого якобы не произошло. VPU-уязвимость описывается как "instantly noticeable with even a cursory audit of the codebase". Два часа аудита - и вот вам "Holy Grail". [Официальная публикация Project Zero с этими цитатами не обнаружена.]
Портирование полной 0-click цепочки на Pixel 10, по неподтверждённым данным, заняло менее суток: адаптация Dolby UDC эксплойта - пересчёт офсетов и замена overwrite target, обнаружение VPU - предположительно два часа аудита, эксплуатация VPU - менее дня. Если эти оценки верны, для достаточно мотивированного атакующего с навыками mobile exploit development перенос exploit chain между поколениями устройств одного производителя - операция с низким порогом входа.
Этот кейс ставит под вопрос один из базовых аргументов в дискуссии о mobile security: тезис о том, что 0-click эксплуатация - привилегия "most well-resourced attackers". По неподтверждённым оценкам, приписываемым Project Zero, трудозатраты на CVE-2025-54957 exploit составили 8 человеко-недель, на BigWave - 3 недели, на VPU - менее дня. Это ресурсы небольшой offensive-команды, не nation-state уровня. Две уязвимости (Dolby UDC и BigWave) предположительно найдены менее чем за два дня рецензирования каждая. Качество кода проприетарных компонентов (Dolby blob, Pixel-specific драйверы) - слабое звено, не поддающееся стандартному patch-процессу.
Расхождение между CVSS 9.8 от NVD и заниженными оценками от вендоров, между initial Moderate от Android VRP для BigWave и реальным impact (root через 0-click) - не теоретическая проблема. Severity-рейтинг влияет на приоритет патчинга. Когда критическая уязвимость маркируется как Important или Moderate, она попадает в следующий квартальный цикл вместо экстренного OTA. 139 дней - вот что происходит, когда CVSS вендора (7.0 по MSRC) и CVSS NVD (9.8) существенно расходятся.
Для тех, кто занимается vulnerability research на ARM64, этот кейс наглядно показывает, куда смотреть. Проприетарные бинарные блобы с минимальной символьной информацией, аппаратные драйверы без серьёзного security-аудита, bump-аллокаторы без metadata - всё это не наследие прошлого десятилетия, а production-код 2025 года на flagship-устройствах. RET PAC усложняет exploitation, но не блокирует. MTE мог бы решить проблему - но по умолчанию выключен. Seccomp мог бы ограничить blast radius - но не применяется к
mediacodec на Pixel. Каждая митигация по отдельности недостаточна, и даже в комбинации они работают только при корректной конфигурации. А конфигурация на флагмане Google оказалась далеко не оптимальной. Если хочешь превратить integer overflow в controlled write на практике - задачи по binary exploitation на HackerLab.pro дают именно такие примитивы, где нужно собрать рабочую цепочку самостоятельно, от trigger до захвата управления.
