
CVE-2026-0091, nutzt einen Fehler in der Android-Fensterverwaltung aus, um beliebige Codeausführung im Launcher-Prozess von adb durchzuführen.
Dieses Problem wurde für Android 14+ im June 2026 Android Security Bulletin behoben. Klicken Sie hier, um den Patch zu sehen
TODO
Ich werde den Writeup vervollständigen, wenn ich etwas freie Zeit habe
Aber davor muss ich mich mit Schularbeiten und Prüfungen herumschlagen
Ich habe beschlossen, den Abschnitt vor dem Ende der Prüfungen fertigzustellen
Viel Glück für mich 😇
IApplicationThread ist ein privater Callback, der dem System von Apps bereitgestellt wird, damit das System es verwenden kann, um Befehle an die App zu senden (bestimmte App laden, Änderungen des Komponentenlebenszyklus benachrichtigen usw.)
Es ist nur vom System aus nutzbar, daher gibt es keine Berechtigungsprüfungen, und die Sicherheit wird ausschließlich dadurch gewährleistet, dass das Objekt nicht von einem bösartigen Prozess erlangt wird.
Dies klingt etwas ähnlich wie das Konzept von "Cookies" oder "Tokens" im Web.
Ein solches Zugriffskontrollmodell wird als Capability-basierte Sicherheit bezeichnet
Wenn es jemandem gelingt, ein IApplicationThread von anderen Prozessen zu erhalten, kann er beliebige Befehle senden, und die Opfer-App würde die fabrizierten Befehle so verarbeiten, als wären sie vom System erzeugt worden.
In einem früheren Exploit von CVE-2022-20452 wurde der Trick verwendet, um beliebigen Code auszuführen
Obwohl IApplicationThread nur an den Systemprozess weitergegeben werden sollte, kann es unerwartet aus system_server herausgesendet werden
Niemand würde eine getIApplicationThreadForApp(String packageName)-API implementieren, die für jedermann offen ist, das wäre eine offensichtliche Sicherheitsverletzung
Aber wenn IApplicationThread in ein anderes Objekt eingewickelt wird und das äußere Wrapper-Objekt gesendet wird, ist das ein wahrscheinlicheres Szenario
RemoteTransition ist ein solcher Wrapper, der ein IApplicationThread enthält, um die Priorität einer App zu erhöhen, die eine Animation ausführt
Ein Nutzer dieser API ist Launcher3, die Standard-Startbildschirm-App auf AOSP- und Pixel-Geräten, die eine ActivityOptions mit einem RemoteTransition erstellt und diese dann an startActivity() übergibt
Während Launcher3 selbst das Objekt nicht unvertrauenswürdigen Faktoren aussetzt, tut system_server dies manchmal
CVE-2022-20419 trat auf, weil system_server die vom Aufrufer übergebenen ActivityOptions an die gestartete App weiterleitete, aber vergaß, RemoteTransition zu entfernen, so dass die gestartete App es empfangen und beliebigen Code im Launcher-Prozess laden konnte
Während der Shared-Element-Übergangsanimation muss viel Arbeit geleistet werden, und es müssen Kommunikationen zwischen WMCore und WMShell stattfinden, wobei WM für Window Manager steht
Sie können diesen Artikel lesen, um WMShell zu verstehen
Da WMCore und WMShell in verschiedenen Prozessen laufen (WMCore läuft in system_server und WMShell in SystemUI), nutzen sie den Binder-Mechanismus, um miteinander zu kommunizieren
WMCore stellt eine Binder registerTransitionPlayer API zur Verfügung und WMShell verwendet sie, um seinen eigenen Binder zu registrieren
Wenn eine Animation gestartet wird, ruft WMCore requestStartTransition auf, und TransitionRequestInfo wird an den Remote-Prozess übergeben, das das anfängliche RemoteTransition enthält
Wenn wir also den Transition Player ersetzen können, können wir das IApplicationThread des Launchers abrufen und eine beliebige Codeausführung in einem privilegierten Prozess erreichen
Jedoch ist registerTransitionPlayer durch die MANAGE_ACTIVITY_TASKS-Berechtigung geschützt, die eine Drittanbieter-App nicht erhalten kann
Aber adb shell kann ebenfalls nicht vertrauenswürdigen Benutzercode ausführen, und der Shell wird die MANAGE_ACTIVITY_TASKS-Berechtigung gewährt, daher können wir glücklicherweise einen Angriff von der adb shell aus starten
Es ist eine lustige Frage, was Angreifer durch diese Sicherheitslücke tun können
Da die meisten Berechtigungen, die dem Launcher gewährt werden, auch von der adb shell gehalten werden, müssen Angreifer, die bereits in der Lage sind, Code unter der Shell-Identität auszuführen, diese Sicherheitslücke nicht ausnutzen, um das Gerät zu kompromittieren
Dies ist eher ein pädagogisches Beispielprojekt zum Erlernen von IApplicationThread als ein Exploit, der von einer bösartigen App verwendet werden kann
Allerdings könnte jemand trotzdem daran interessiert sein
Zum Beispiel kann dies verwendet werden, um private Dateien des Launchers zu extrahieren, was bei forensischen Analysen für bösartige Launcher-Apps nützlich sein kann, ohne das Gerät zu rooten.
Zuvor wurde dies durch Ausnutzung von CVE-2024-31317 erreicht, und mein Fund enthüllt eine weitere Methode, nachdem die vorherige behoben wurde
Dies ermöglicht es Benutzern auch, Fabricated Runtime Resources Overlay (FRRO) zu verwenden, ohne ihr Gerät zu rooten, sodass rootless custom themes nach der Behebung von CVE-2021-39630 zurück sind.
Mein Exploit hat dies demonstriert, indem er android:integer/config_multiuserMaximumUsers auf 100 setzt
Darüber hinaus hostet der Launcher standardmäßig auch die Recents-Bildschirmkomponente und ist daher für einige privilegierte Aktionen auf der Whitelist.
Ich denke, der Launcher darf eine beliebige Aktivität in einer vorhandenen Aufgabe starten, unabhängig von den Export-/Berechtigungseinstellungen der gestarteten Aktivitäten, was von einigen Geräteverwaltungs-Tool-Apps gewünscht sein könnte, obwohl ich es selbst nicht getestet habe
Erstellen Sie das Projekt, installieren Sie die generierte APK-Datei (wenn Sie die Schaltfläche "Ausführen" in Android Studio verwenden, aktivieren Sie "Immer mit Paketmanager installieren")
Führen Sie den folgenden Befehl auf dem PC aus
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
Starten Sie dann eine beliebige App, indem Sie auf ihr Symbol im Launcher tippen
Eine Benachrichtigung sollte von der Launcher-App gesendet werden, und wenn Sie Android 14+ verwenden, wird ein fabriziertes Overlay in das System injiziert, sodass adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers 100 zurückgeben sollte