canyie/transitionplayerCVE-2026-0091, explore um problema no gerenciamento de janelas do Android para executar código arbitrário no processo Launcher a partir do adb
Esta questão foi corrigida para Android 14+ no Boletim de Segurança do Android de Junho de 2026. Clique aqui para ver o patch
A FAZER
Completarei o writeup quando tiver um pouco de tempo livre
Mas antes disso tenho que lutar contra trabalhos escolares e exames
Decidi completar a secção antes que os exames terminem
Boa sorte para mim 😇
IApplicationThread é um callback privado fornecido pelo sistema para as aplicações, para que o sistema possa usá-lo para enviar comandos (carregar app especificada, notificar mudanças no ciclo de vida de componentes, etc) para a app
Destina-se a ser utilizável apenas pelo sistema, por isso não há verificações de permissão, e a segurança é garantida unicamente pelo facto de o objeto não ser obtido por um processo malicioso. Isto soa um pouco semelhante ao conceito de "cookies" ou "tokens" na web. Tal modelo de controlo de acesso é chamado de Segurança Baseada em Capacidades
Se alguém conseguir obter um IApplicationThread de outros processos, pode enviar comandos arbitrários e a aplicação vítima processaria os comandos fabricados como se fossem gerados pelo sistema. Num exploit anterior do CVE-2022-20452 o truque foi usado para executar código arbitrário
Embora o IApplicationThread deva ser passado apenas para o processo do sistema, ele pode ser inesperadamente enviado para fora do system_server
Ninguém implementaria uma API getIApplicationThreadForApp(String packageName) exposta a qualquer um, é uma violação de segurança óbvia
Mas se o IApplicationThread for encapsulado noutro objeto e o objeto exterior for enviado, é um cenário mais provável
RemoteTransition é um desses encapsuladores que contém um IApplicationThread para aumentar a prioridade da app que está a executar uma animação
Um utilizador dessa API é o Launcher3, a aplicação inicial padrão no AOSP e dispositivos Pixel, que cria um ActivityOptions usando um RemoteTransition e depois passa-o para startActivity()
Embora o próprio Launcher3 não exponha o objeto a fatores não confiáveis, o system_server por vezes expõe
O CVE-2022-20419 ocorreu porque o system_server encaminhou o ActivityOptions passado pelo chamador para a aplicação lançada, mas esqueceu-se de remover o RemoteTransition, permitindo que a app lançada o recebesse e carregasse código arbitrário dentro do processo do launcher
Durante a animação de transição de elemento partilhado, muito trabalho tem de ser feito e as comunicações precisam de ocorrer entre o WMCore e o WMShell, onde WM significa Window Manager
Pode ler este artigo para entender o WMShell
Como o WMCore e o WMShell executam em processos diferentes (o WMCore executa no system_server e o WMShell executa no SystemUI), utilizam o mecanismo Binder para comunicar entre si
O WMCore expôs uma API Binder registerTransitionPlayer e o WMShell usa-a para registar o seu próprio binder
Quando a animação é iniciada, o WMCore chama requestStartTransition e o TransitionRequestInfo é passado para o remoto, que inclui o RemoteTransition inicial
Portanto, se conseguirmos substituir o transition player, seremos capazes de obter o IApplicationThread do Launcher e executar código arbitrário dentro de um processo privilegiado
No entanto, o registerTransitionPlayer é protegido pela permissão MANAGE_ACTIVITY_TASKS que uma app de terceiros não consegue obter
Mas o adb shell também pode executar código de utilizador não confiável, e ao shell é concedida a permissão MANAGE_ACTIVITY_TASKS, portanto, felizmente, podemos lançar o ataque a partir do adb shell
É uma questão engraçada o que os atacantes podem fazer através desta vulnerabilidade
Como a maioria das permissões concedidas ao Launcher também são detidas pelo adb shell, os atacantes que já conseguem executar código sob a identidade do shell não precisam de explorar esta vulnerabilidade para comprometer o dispositivo
Isto é mais um projeto de exemplo educacional para aprender o IApplicationThread do que um exploit que possa ser usado por uma app maliciosa
No entanto, alguém pode ainda estar interessado neste
Por exemplo, isto pode ser usado para extrair ficheiros privados do Launcher, o que pode ser útil na análise forense de apps Launcher maliciosas sem rootear o dispositivo. Anteriormente isto foi conseguido através da exploração do CVE-2024-31317, e a minha descoberta revela outro método depois de o anterior ter sido corrigido
Isto também permite que os utilizadores usem Overlay de Recursos de Runtime Fabricados (FRRO) sem primeiro rootear o seu dispositivo, portanto, os temas personalizados sem root estão de volta depois de o CVE-2021-39630 ter sido corrigido. O meu exploit demonstrou isto ao definir android:integer/config_multiuserMaximumUsers para 100
Além disso, o Launcher também aloja o componente do ecrã Recents por padrão e, portanto, está na lista de permissões para algumas ações privilegiadas. Penso que o Launcher tem permissão para iniciar atividades arbitrárias numa tarefa existente independentemente das definições de exportação/permissão das Atividades lançadas, o que pode ser desejado por algumas apps de ferramentas de gestão de dispositivos, embora não o tenha testado pessoalmente
Compile o projeto, instale o ficheiro apk gerado (se usar o botão Executar no Android Studio, ative "Sempre instalar com o package manager")
Execute o seguinte comando no PC
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
Em seguida, inicie uma app arbitrária tocando no seu ícone no launcher
Uma notificação deve ser enviada pela app launcher, e se estiver no Android 14+, um overlay fabricado será injetado no sistema, portanto adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers deve retornar 100