canyie/transitionplayerCVE-2026-0091, sfrutta un problema nella gestione delle finestre di Android per eseguire codice arbitrario nel processo Launcher da adb
Questo problema è stato risolto per Android 14+ nel June 2026 Android Security Bulletin. Clicca qui per vedere la patch
TODO
Completerò il writeup quando avrò un po' di tempo libero
Ma prima devo combattere contro i compiti scolastici e gli esami
Ho deciso di completare la sezione prima che gli esami finiscano
Buona fortuna a me 😇
IApplicationThread è un callback privato fornito dal sistema alle app in modo che il sistema possa usarlo per inviare comandi (caricare l'app specificata, notificare cambiamenti del ciclo di vita dei componenti, ecc.) all'app
È pensato per essere utilizzabile solo dal sistema, quindi non ci sono controlli delle autorizzazioni, e la sicurezza è garantita esclusivamente dal fatto che l'oggetto non viene ottenuto da un processo malevolo. Questo ricorda in qualche modo il concetto di "cookie" o "token" nel web. Questo modello di controllo degli accessi è chiamato Capability-based Security
Se qualcun altro riuscisse a ottenere un IApplicationThread da altri processi, potrebbe inviare comandi arbitrari e l'app vittima elaborerebbe i comandi falsificati come se fossero stati generati dal sistema. In un precedente exploit di CVE-2022-20452 il trucco è stato utilizzato per eseguire codice arbitrario
Mentre IApplicationThread dovrebbe essere passato solo al processo di sistema, può essere inaspettatamente inviato fuori da system_server
Nessuno implementerebbe un'API getIApplicationThreadForApp(String packageName) esposta a chiunque, è una palese violazione della sicurezza
Ma se IApplicationThread viene avvolto in un altro oggetto e l'oggetto wrapper esterno viene inviato, è uno scenario più probabile
RemoteTransition è un tale wrapper che contiene un IApplicationThread per aumentare la priorità dell'app che esegue un'animazione
Un utilizzatore di questa API è Launcher3, l'applicazione home predefinita su AOSP e dispositivi Pixel, che crea un ActivityOptions usando un RemoteTransition e poi lo passa a startActivity()
Mentre Launcher3 stesso non espone l'oggetto a fattori non affidabili, a volte lo fa system_server
CVE-2022-20419 si è verificato perché system_server ha inoltrato ActivityOptions passati dal chiamante all'app lanciata ma ha dimenticato di rimuovere RemoteTransition, permettendo all'app lanciata di riceverlo e caricare codice arbitrario all'interno del processo del launcher
Durante l'animazione di transizione degli elementi condivisi, molto lavoro deve essere fatto e le comunicazioni devono avvenire tra WMCore e WMShell, dove WM sta per Window Manager
Puoi leggere questo articolo per capire WMShell
Poiché WMCore e WMShell girano in processi diversi (WMCore gira in system_server e WMShell gira in SystemUI), utilizzano il meccanismo Binder per comunicare tra loro
WMCore espone un Binder registerTransitionPlayer API e WMShell lo usa per registrare il proprio binder
Quando l'animazione viene avviata, WMCore chiama requestStartTransition e TransitionRequestInfo viene passato al remoto, che include il RemoteTransition iniziale
Quindi se possiamo sostituire il player di transizione, saremo in grado di recuperare l'IApplicationThread di Launcher e ottenere l'esecuzione di codice arbitrario all'interno di un processo privilegiato
Tuttavia, registerTransitionPlayer è protetto dal permesso MANAGE_ACTIVITY_TASKS che le app di terze parti non possono ottenere
Ma adb shell può anche eseguire codice utente non fidato, e alla shell è concesso il permesso MANAGE_ACTIVITY_TASKS, quindi fortunatamente possiamo lanciare l'attacco dalla shell adb
È una domanda divertente cosa possano fare gli aggressori attraverso questa vulnerabilità
Poiché la maggior parte dei permessi concessi a Launcher sono anche detenuti dalla shell adb, gli aggressori che sono già in grado di eseguire codice sotto l'identità della shell non hanno bisogno di sfruttare questa vulnerabilità per compromettere il dispositivo
Questo è più un progetto di esempio educativo per imparare IApplicationThread che un exploit che può essere usato da un'app malevola
Tuttavia, qualcuno potrebbe ancora essere interessato a questo
Ad esempio, può essere usato per estrarre i file privati di Launcher, il che può essere utile nell'analisi forense per app Launcher malevole senza rootare il dispositivo. In precedenza questo è stato ottenuto sfruttando CVE-2024-31317, e la mia scoperta rivela un altro metodo dopo che il precedente è stato risolto
Questo permette anche agli utenti di usare Fabricated Runtime Resources Overlay (FRRO) senza prima rootare il loro dispositivo, quindi i temi personalizzati senza root sono tornati dopo che CVE-2021-39630 è stato risolto. Il mio exploit lo ha dimostrato impostando android:integer/config_multiuserMaximumUsers a 100
Inoltre, il Launcher ospita anche il componente della schermata Recents per impostazione predefinita e quindi è inserito nella whitelist per alcune azioni privilegiate. Penso che il Launcher sia autorizzato ad avviare attività arbitrarie in un task esistente indipendentemente dalle impostazioni di export/permesso delle attività lanciate il che potrebbe essere desiderato da alcune app di strumenti di gestione dei dispositivi, anche se non l'ho testato personalmente
Costruisci il progetto, installa il file apk generato (se usi il pulsante Run in Android Studio, attiva "Always install with package manager")
Esegui il seguente comando sul PC
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
Poi avvia un'app arbitraria toccando la sua icona dal launcher
Dovrebbe essere inviata una notifica dall'app launcher, e se sei su Android 14+, un overlay fabbricato verrà iniettato nel sistema, quindi adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers dovrebbe restituire 100