canyie/transitionplayerCVE-2026-0091, exploiter un problème dans la gestion des fenêtres Android pour exécuter du code arbitraire dans le processus Launcher depuis adb
Ce problème a été corrigé pour Android 14+ dans le Bulletin de sécurité Android de juin 2026. Cliquez ici pour voir le correctif
TODO
Je compléterai l'exposé quand j'aurai un peu de temps libre
Mais avant cela, je dois lutter contre le travail scolaire et les examens
J'ai décidé de compléter la section avant que les examens ne soient terminés
Bonne chance à moi 😇
IApplicationThread est un callback privé fourni au système par les applications afin que le système puisse l'utiliser pour envoyer des commandes (charger une application spécifiée, notifier les changements du cycle de vie des composants, etc.) à l'application
Il est prévu pour être utilisable uniquement par le système, donc il n'y a pas de vérifications de permissions, et la sécurité est garantie uniquement par le fait que l'objet n'est pas obtenu par un processus malveillant. Cela ressemble un peu au concept de « cookies » ou de « jetons » dans le web. Ce modèle de contrôle d'accès est appelé sécurité basée sur les capacités
Si quelqu'un d'autre parvenait à obtenir un IApplicationThread depuis d'autres processus, il pourrait envoyer des commandes arbitraires et l'application victime traiterait ces commandes fabriquées comme si elles avaient été générées par le système. Dans une exploitation précédente de CVE-2022-20452, cette astuce a été utilisée pour exécuter du code arbitraire
Bien que IApplicationThread ne devrait être transmis qu'au processus système, il peut être envoyé de manière inattendue en dehors de system_server
Personne n'implémenterait une API getIApplicationThreadForApp(String packageName) exposée à n'importe qui, c'est une violation de sécurité évidente
Mais si IApplicationThread est encapsulé dans un autre objet et que l'objet enveloppe externe est envoyé, c'est un scénario plus probable
RemoteTransition est un tel wrapper qui contient un IApplicationThread afin d'augmenter la priorité de l'application qui exécute une animation
Un utilisateur de cette API est Launcher3, l'application d'accueil par défaut sur les appareils AOSP et Pixel, qui crée des ActivityOptions à l'aide d'un RemoteTransition puis le transmet à startActivity()
Bien que Launcher3 lui-même n'expose pas l'objet à des facteurs non fiables, system_server le fait parfois
CVE-2022-20419 s'est produit parce que system_server a transmis les ActivityOptions passées par l'appelant à l'application lancée mais a oublié de supprimer RemoteTransition, permettant à l'application lancée de le recevoir et de charger du code arbitraire dans le processus du launcher
Lors de l'animation de transition d'élément partagé, beaucoup de travail doit être effectué et des communications doivent avoir lieu entre WMCore et WMShell, où WM signifie Window Manager
Vous pouvez lire cet article pour comprendre WMShell
Comme WMCore et WMShell s'exécutent dans des processus différents (WMCore s'exécute dans system_server et WMShell dans SystemUI), ils utilisent le mécanisme Binder pour communiquer entre eux
WMCore a exposé une API Binder registerTransitionPlayer et WMShell l'utilise pour enregistrer son propre binder
Lorsque l'animation est démarrée, WMCore appelle requestStartTransition et TransitionRequestInfo est passé au processus distant, qui inclut le RemoteTransition initial
Donc si nous pouvons remplacer le player de transition, nous pourrons récupérer le IApplicationThread de Launcher et exécuter du code arbitraire dans un processus privilégié
Cependant, registerTransitionPlayer est protégé par la permission MANAGE_ACTIVITY_TASKS que les applications tierces ne peuvent pas obtenir
Mais adb shell peut également exécuter du code utilisateur non fiable, et le shell se voit accorder la permission MANAGE_ACTIVITY_TASKS, donc heureusement nous pouvons lancer l'attaque depuis adb shell
C'est une question amusante de savoir ce que les attaquants peuvent faire via cette vulnérabilité
Comme la plupart des permissions accordées à Launcher sont également détenues par adb shell, les attaquants qui sont déjà capables d'exécuter du code sous l'identité du shell n'ont pas besoin d'exploiter cette vulnérabilité pour compromettre l'appareil
C'est plus un projet d'exemple éducatif pour apprendre IApplicationThread qu'une exploitation utilisable par une application malveillante
Cependant, quelqu'un pourrait encore être intéressé par celui-ci
Par exemple, cela peut être utilisé pour extraire les fichiers privés de Launcher, ce qui peut être utile dans une analyse forensique pour les applications Launcher malveillantes sans rooter l'appareil. Auparavant, cela avait été réalisé en exploitant CVE-2024-31317, et ma découverte révèle une autre méthode après que la précédente a été corrigée
Cela permet également aux utilisateurs d'utiliser Fabricated Runtime Resources Overlay (FRRO) sans d'abord rooter leur appareil, donc les thèmes personnalisés sans root sont de retour après que CVE-2021-39630 a été corrigé. Mon exploit a démontré cela en définissant android:integer/config_multiuserMaximumUsers à 100
De plus, le Launcher héberge également le composant de l'écran Récents par défaut et est donc autorisé pour certaines actions privilégiées. Je pense que le Launcher est autorisé à démarrer une activité arbitraire dans une tâche existante indépendamment des paramètres d'exportation/permission des activités lancées ce qui pourrait être souhaité par certaines applications d'outils de gestion d'appareils, bien que je ne l'aie pas testé moi-même
Compilez le projet, installez le fichier apk généré (si vous utilisez le bouton Exécuter dans Android Studio, activez "Toujours installer avec le gestionnaire de packages")
Exécutez la commande suivante sur le PC
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
Lancez ensuite une application arbitraire en appuyant sur son icône depuis le launcher
Une notification devrait être envoyée depuis l'application launcher, et si vous êtes sur Android 14+, un overlay fabriqué sera injecté dans le système, donc adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers devrait retourner 100