TransitionPlayer exploit

Эта проблема исправлена для Android 14+ в Бюллетене безопасности Android за июнь 2026. Нажмите здесь, чтобы увидеть патч

~~Закончу разбор, когда появится немного свободного времени~~

~~Но перед этим нужно бороться со школьными заданиями и экзаменами~~

Я решил закончить раздел до окончания экзаменов

`IApplicationThread` — это приватный колбэк, предоставляемый системе приложениями, чтобы система могла использовать его для отправки команд (загрузка указанного приложения, уведомление об изменениях жизненного цикла компонентов и т.д.) приложению

Он предназначен только для использования системой, поэтому проверки разрешений отсутствуют, и безопасность гарантируется исключительно тем фактом, что объект не получает вредоносный процесс. Это похоже на концепцию «куки» или «токенов» в вебе. Такая модель управления доступом называется Capability-based Security (безопасность на основе возможностей)

Если кому-то удастся получить `IApplicationThread` из других процессов, он сможет отправлять произвольные команды, и приложение-жертва будет обрабатывать поддельные команды так, как будто они были сгенерированы системой. В предыдущем эксплойте CVE-2022-20452 этот трюк использовался для выполнения произвольного кода

Хотя `IApplicationThread` должен передаваться только системному процессу, он может быть неожиданно отправлен за пределы system_server

Никто не стал бы реализовывать API `getIApplicationThreadForApp(String packageName)`, доступный кому угодно — это очевидное нарушение безопасности

Но если `IApplicationThread` обёрнут в другой объект, и внешний объект-обёртка отправляется, это более вероятный сценарий

`RemoteTransition` — это такая обёртка, которая содержит `IApplicationThread` для повышения приоритета приложения, выполняющего анимацию

Одним из пользователей этого API является Launcher3 — стандартное домашнее приложение на AOSP и устройствах Pixel, которое создаёт ActivityOptions с помощью RemoteTransition и затем передаёт его в `startActivity()`

Хотя сам Launcher3 не предоставляет объект ненадёжным сторонам, system_server иногда это делает

CVE-2022-20419 произошёл, потому что system_server переслал переданные вызывающим `ActivityOptions` запущенному приложению, но забыл удалить `RemoteTransition`, что позволило запущенному приложению получить его и загрузить произвольный код внутри процесса лаунчера

Во время анимации перехода с общими элементами требуется много работы, и коммуникации должны происходить между `WMCore` и `WMShell`, где `WM` означает `Window Manager`

Вы можете прочитать эту статью, чтобы понять `WMShell`

Поскольку `WMCore` и `WMShell` работают в разных процессах (`WMCore` — в system_server, а `WMShell` — в SystemUI), они используют механизм Binder для общения

`WMCore` предоставляет Binder API регистрации `registerTransitionPlayer`, и `WMShell` использует его для регистрации своего собственного binder

Когда анимация запускается, `WMCore` вызывает `requestStartTransition`, и `TransitionRequestInfo` передаётся удалённому процессу, который включает начальный RemoteTransition

Итак, если мы сможем заменить проигрыватель переходов, мы сможем получить `IApplicationThread` лаунчера и выполнить произвольный код внутри привилегированного процесса

Однако, `registerTransitionPlayer` защищён разрешением `MANAGE_ACTIVITY_TASKS`, которое стороннее приложение не может получить

Но `adb shell` также может выполнять ненадёжный пользовательский код, и shell предоставлено разрешение `MANAGE_ACTIVITY_TASKS`, так что, к счастью, мы можем запускать атаку из adb shell

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

Поскольку большинство разрешений, предоставленных лаунчеру, также есть у adb shell, злоумышленники, уже способные выполнять код под идентификатором оболочки, не нуждаются в эксплуатации этой уязвимости для компрометации устройства

Это скорее образовательный пример для изучения `IApplicationThread`, чем эксплойт, который может быть использован вредоносным приложением

Тем не менее, кто-то может быть заинтересован в этом

Например, это можно использовать для извлечения приватных файлов лаунчера, что может быть полезно при криминалистическом анализе вредоносных приложений-лаунчеров без рутирования устройства. Ранее это достигалось эксплуатацией CVE-2024-31317, и моя находка раскрывает другой метод после того, как предыдущий был исправлен

Это также позволяет пользователям использовать Fabricated Runtime Resources Overlay (FRRO) без предварительного рутирования устройства, так что rootless custom themes возвращаются после исправления CVE-2021-39630. Мой эксплойт продемонстрировал это, установив `android:integer/config_multiuserMaximumUsers` в 100

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

Соберите проект, установите сгенерированный apk-файл (если используете кнопку Run в Android Studio, включите «Always install with package manager»)

adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'

Затем запустите произвольное приложение, нажав на его значок в лаунчере

Должно быть отправлено уведомление от приложения лаунчера, а если вы на Android 14+, в систему будет внедрён fabricated overlay, так что `adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers` должен вернуть 100

* Механизм делегирования анимации был переработан, и дескриптор IApplicationThread больше не отправляется за пределы WindowManagerService

* Начиная с Android 17, вызов IApplicationThread будет отклонён, если он не от системы. Я не считаю это эффективным способом смягчения таких эксплойтов, так как, думаю, атакующие могут обмануть ActivityManagerService, заставив его совершать вызовы с контролируемым атакующим путём к apk в целевой процесс (хотя я сам не тестировал это), но это сигнал, что команда безопасности Android начинает принимать меры