canyie/transitionplayerCVE-2026-0091, juega con un problema en la gestión de ventanas de Android para ejecutar código arbitrario en el proceso de Launcher desde adb
Este problema se ha corregido para Android 14+ en el Boletín de Seguridad de Android de junio de 2026. Haz clic aquí para ver el parche
TODO
Completaré el writeup cuando tenga un poco de tiempo libre
Pero antes tengo que luchar contra los deberes y los exámenes
Decidí completar la sección antes de que terminen los exámenes
Buena suerte para mí 😇
IApplicationThread es un callback privado que las aplicaciones entregan al sistema para que este pueda usarlo para enviar comandos a la aplicación (cargar una aplicación específica, notificar cambios en el ciclo de vida de los componentes, etc.)
Está diseñado para ser utilizado únicamente por el sistema, por lo que no hay comprobaciones de permisos, y la seguridad queda garantizada únicamente por el hecho de que un proceso malicioso no obtenga el objeto. Esto suena algo similar al concepto de «cookies» o «tokens» en la web. Este modelo de control de acceso se denomina seguridad basada en capacidades
Si alguien consiguiera obtener un IApplicationThread de otros procesos, podría enviar comandos arbitrarios y la aplicación víctima procesaría los comandos fabricados como si hubieran sido generados por el sistema. En un exploit anterior de CVE-2022-20452 el truco se utilizó para lograr la ejecución de código arbitrario
Aunque IApplicationThread solo debería pasarse al proceso del sistema, puede enviarse inesperadamente fuera de system_server
Nadie implementaría una API getIApplicationThreadForApp(String packageName) expuesta a cualquiera; es una violación de seguridad evidente
Pero si IApplicationThread se envuelve en otro objeto y se envía el objeto contenedor externo, es un escenario más probable
RemoteTransition es uno de esos contenedores: contiene un IApplicationThread para aumentar la prioridad de la aplicación que está ejecutando una animación
Uno de los usuarios de esa API es Launcher3, la aplicación de inicio predeterminada en los dispositivos AOSP y Pixel, que crea un ActivityOptions usando un RemoteTransition y luego lo pasa a startActivity()
Aunque Launcher3 en sí no expone el objeto a partes no confiables, system_server a veces sí lo hace
CVE-2022-20419 ocurrió porque system_server reenviaba el ActivityOptions pasado por el llamador a la aplicación lanzada, pero olvidó eliminar el RemoteTransition, lo que permitía que la aplicación lanzada lo recibiera y cargara código arbitrario dentro del proceso del launcher
Durante la animación de transición de elementos compartidos, hay que realizar mucho trabajo y es necesario que se produzcan comunicaciones entre WMCore y WMShell, donde WM significa Window Manager
Puedes leer este artículo para entender WMShell
Como WMCore y WMShell se ejecutan en procesos diferentes (WMCore se ejecuta en system_server y WMShell en SystemUI), utilizan el mecanismo Binder para comunicarse entre sí
WMCore expone una API Binder registerTransitionPlayer y WMShell la utiliza para registrar su propio binder
Cuando se inicia la animación, WMCore llama a requestStartTransition y se pasa a la parte remota un TransitionRequestInfo, que incluye el RemoteTransition inicial
Así que, si podemos reemplazar el transition player, podremos recuperar el IApplicationThread del Launcher y lograr la ejecución de código arbitrario dentro de un proceso privilegiado
Sin embargo, registerTransitionPlayer está protegida por el permiso MANAGE_ACTIVITY_TASKS, que una aplicación de terceros no puede obtener
Pero adb shell también puede ejecutar código de usuario no confiable y a la shell se le concede el permiso MANAGE_ACTIVITY_TASKS, así que, afortunadamente, podemos lanzar el ataque desde adb shell
Es una pregunta curiosa qué pueden hacer los atacantes a través de esta vulnerabilidad
Como la mayoría de los permisos concedidos al Launcher también los tiene adb shell, los atacantes que ya pueden ejecutar código bajo la identidad de shell no necesitan explotar esta vulnerabilidad para comprometer el dispositivo
Esto es más un proyecto de ejemplo educativo para aprender sobre IApplicationThread que un exploit que pueda usar una aplicación maliciosa
Sin embargo, puede que a alguien todavía le interese
Por ejemplo, esto se puede usar para extraer los archivos privados del Launcher, lo que puede ser útil en el análisis forense de aplicaciones Launcher maliciosas sin rootear el dispositivo. Anteriormente esto se logró explotando CVE-2024-31317, y mi hallazgo revela otro método después de que el anterior fuera corregido
Esto también permite a los usuarios usar Fabricated Runtime Resources Overlay (FRRO) sin tener que rootear primero su dispositivo, por lo que los temas personalizados sin root vuelven después de que se parcheara CVE-2021-39630. Mi exploit ha demostrado esto estableciendo android:integer/config_multiuserMaximumUsers en 100
Además, el Launcher también aloja el componente de la pantalla Recientes de forma predeterminada y, por lo tanto, está en la lista blanca para algunas acciones privilegiadas. Creo que el Launcher puede iniciar una actividad arbitraria en una tarea existente sin importar la configuración de exported/permisos de las actividades lanzadas, lo que podría ser deseado por algunas aplicaciones de herramientas de gestión de dispositivos, aunque yo no lo he probado personalmente
Compila el proyecto e instala el archivo apk generado (si usas el botón Run dentro de Android Studio, activa «Instalar siempre con el administrador de paquetes»)
Ejecuta el siguiente comando en el PC
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
Luego, inicia una aplicación arbitraria tocando su icono desde el launcher
Se debería enviar una notificación desde la aplicación del launcher y, si estás en Android 14+, se inyectará un overlay fabricado en el sistema, por lo que adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers debería devolver 100