CVE-2026-20516: MiracastService confused deputy on Android TV

Исследование и раскрытие информации: Davide Di Matteo (@Dingo97).

Это мой первый CVE, зачтённый в мой счёт. Я обнаружил неправильно экспортированный системно-привилегированный сервис Miracast во время исследования PEAQ Android TV. Вызывающая сторона может передать extra-параметр intent, который заставляет сервис изменять состояние Wi-Fi Direct, используя собственные привилегии.

MediaTek опубликовала эту проблему в своём бюллетене безопасности за сентябрь 2026 года и указывает Davide Di Matteo в своих благодарностях по безопасности. Эта статья и оригинальное воспроизведение через ADB публикуются после скоординированного раскрытия и с разрешения вендора.

Читать на моём сайте · Репозиторий GitHub

Краткое описание уязвимости

Влияние, идентификаторы патчей и предварительные условия локальной атаки задокументированы в записи CVE. Числовая оценка и вектор выше — это те, что опубликованы Tenable. Они заменяют предварительную оценку 5.1 из моего первоначального отчёта. CWE-284 (improper access control) и CWE-441 (confused deputy) описывают первоначальный анализ; MediaTek классифицирует проблему как CWE-926.

Тестовая среда

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

Первопричина

Анализ манифеста, зафиксированный в первоначальном отчёте, показывает, что MiracastService экспортируется с android:exported="true", без разрешения, защищающего доступ к сервису. Приложение объявляет android:sharedUserId="android.uid.system".

Метод onStartCommand() сервиса читает булев extra-параметр intent screen_share, не проверяя, уполномочена ли вызывающая сторона управлять Miracast. Затем сервис выполняет операции в собственном привилегированном контексте. Это и есть confused deputy: вызывающая сторона предоставляет запрос, а системный сервис предоставляет полномочия.

В проанализированной реализации путь screen_share=false может вызвать WifiP2pManager.createGroup(). Вызов условный: демонстрация экрана должна быть отключена в состоянии сервиса, Wi-Fi P2P должен быть включён, и группа ещё не должна существовать. Имя булевой переменной не следует интерпретировать как прямое утверждение о том, будет ли создана или удалена группа.

В отчёте также зафиксирована запись в Settings.Global.putInt(..., "miracast_enable", 1) в onCreate(). Таким образом, запуск жизненного цикла сервиса может вызвать запись в защищённые настройки через сервис. Это наблюдение из анализа реализации; приведённый ниже фрагмент лога не демонстрирует эту запись независимо.

Соответствующие проверки разрешений зависят от фреймворка Android и сборки OEM. Ключевая проблема — отсутствие авторизации на границе экспортированного сервиса, а не утверждение о том, что каждая версия Android применяет идентичный набор разрешений для Wi-Fi Direct.

Влияние и границы доказательств

MediaTek описывает риск локального отказа в обслуживании. На протестированном телевизоре записанная сессия ADB показывает, что сервис принимает screen_share=false и успешно создаёт группу Wi-Fi Direct. Неожиданные изменения этого состояния могут помешать легитимному использованию Miracast и могут привести к раскрытию состояния приёмника, которое пользователь не запрашивал.

Экспортированный компонент и отсутствие контроля доступа подтверждают путь атаки через локальное приложение в первоначальном анализе. ADB shell работает под идентификатором Android shell, а не под обычным UID приложения. Следовательно, эти команды и логи демонстрируют поведение сервиса из ADB; сами по себе они не доказывают выполнение из приложения с нулевыми разрешениями. Этот репозиторий не содержит отдельно протестированного воспроизведения на основе приложения.

Фрагмент не устанавливает произвольное выполнение кода, root-оболочку, завершённое подключение от nearby-устройства или успешное удаление группы. Вызывающая сторона не получает системный UID сервиса; она побуждает сервис действовать от её имени.

Доказательство концепции

Предварительные условия

• Протестированная уязвимая прошивка или эквивалентная сборка, предоставляющая тот же компонент.
• ADB, установленный на хосте, и авторизованное отладочное подключение к телевизору, которым вы владеете или который уполномочены тестировать.
• Wi-Fi и Wi-Fi Direct, доступные на телевизоре.
• Два терминала. Приведённые ниже команды хоста используют POSIX-оболочку, например Bash или WSL с доступом к ADB.

Ниже приведено ручное воспроизведение из первоначального отчёта. Оно изменяет состояние Miracast и принудительно останавливает пакет приёмника. Запишите текущее состояние трансляции перед запуском.

1. Мониторинг сервиса

В первом терминале:

adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'

2. Подготовка состояния приёмника

Во втором терминале:

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true
sleep 3
adb shell am force-stop com.mediatek.androidbox
sleep 2

Это последовательность сброса, использованная в первоначальном воспроизведении. Принудительная остановка пакета не гарантирует, что подсистема Wi-Fi Android удалила существующую группу. Если группа сохраняется, сбросьте приёмник через элементы управления телевизора и проверьте его состояние перед повторной попыткой.

3. Запрос создания группы

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false

Ищите Enter createGroup, за которым следует createGroup success. Если появляется только Received screen_share tag, intent был обработан, но создание группы не продемонстрировано: проверьте предварительные условия, описанные выше.

4. Запрос очистки и проверка телевизора

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true

Это отправляет значение очистки, использованное в первоначальном отчёте. Убедитесь, что трансляция и Wi-Fi Direct вернулись в предполагаемое состояние, используя элементы управления телевизора. Получение intent само по себе не является доказательством успешной очистки; при необходимости восстановите приёмник вручную.

Зафиксированные доказательства

Следующий фрагмент logcat был записан на протестированном телевизоре 10 марта 2026 года. Это доказательство из первоначального исследования, а не новый тест, выполненный для этой публикации.

03-10 19:40:27.458 30288 30288 I MiracastService: Received screen_share tag: false
03-10 19:40:27.460 30288 30288 D MiracastService:  Enter createGroup
03-10 19:40:27.530 30288 30288 D MiracastService:  createGroup success
03-10 19:41:19.148 30288 30288 I MiracastService: Received screen_share tag: true

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

Затронутая область

Моё воспроизведение ограничено конфигурацией PEAQ AI PONT, указанной выше. Бюллетень MediaTek перечисляет затронутые чипсеты помимо этого устройства; обратитесь к записи вендора о CVE-2026-20516 для авторитетной области. Включение чипсета не определяет, получил ли конкретный розничный телевизор исправление прошивки от OEM.

Именование пакета и APK предполагало общий компонент MediaTek/Changhong во время первоначального исследования. Это наблюдение само по себе не устанавливает наличие этого экспортированного сервиса на каждом телевизоре на базе MediaTek.

Устранение

Владельцам устройств следует получить прошивку, содержащую соответствующее исправление, от производителя телевизора. MediaTek идентифицирует исправления как ALPS11060069 / DTV04881615; ни одна исправленная версия прошивки PEAQ не была проверена в рамках этой статьи.

Сопровождающим компонента следует устранить внешнее воздействие с помощью android:exported="false", если внешние вызывающие стороны не нужны. Если требуется доверенный межприложенческий доступ, защитите сервис соответствующим разрешением уровня подписи и обеспечьте авторизацию перед изменением состояния приёмника. Проверьте все точки входа и побочные эффекты жизненного цикла, включая записи в защищённые настройки.

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

Хронология раскрытия и благодарности

Обнаружено и о сообщено Davide Di Matteo. Спасибо MediaTek за координацию раскрытия и признание исследования в своих благодарностях за сентябрь 2026 года.

Ссылки

• MediaTek — September 2026 Security Bulletin
• MediaTek — Security Acknowledgements
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516