canyie/transitionplayerCVE-2026-0091, Android 창 관리의 문제를 이용하여 adb에서 Launcher 프로세스에 임의 코드 실행을 수행
이 문제는 Android 14+에서 2026년 6월 Android 보안 게시판에서 수정되었습니다. 패치를 보려면 여기를 클릭하세요
TODO
시간이 조금 생기면 분석글을 완성하겠습니다
하지만 그 전에 학교 과제와 시험과 싸워야 합니다
시험이 끝나기 전에 이 섹션을 완성하기로 결정했습니다
행운을 빕니다 😇
IApplicationThread는 시스템이 앱에 명령(지정된 앱 로드, 컴포넌트 생명주기 변경 알림 등)을 보내기 위해 사용할 수 있도록 앱이 시스템에 제공하는 비공개 콜백입니다.
시스템에서만 사용할 수 있도록 의도되었으며, 따라서 권한 검사가 없습니다. 보안은 오직 악의적인 프로세스가 해당 객체를 획득하지 못한다는 사실에 의해서만 보장됩니다. 이는 웹에서의 '쿠키' 또는 '토큰' 개념과 다소 유사합니다. 이러한 접근 제어 모델을 Capability-based Security라고 합니다.
만약 다른 사람이 다른 프로세스에서 IApplicationThread를 획득한다면, 임의의 명령을 보낼 수 있으며 피해자 앱은 마치 시스템이 생성한 것처럼 조작된 명령을 처리하게 됩니다. CVE-2022-20452의 이전 익스플로잇에서는 이 트릭을 사용하여 임의 코드 실행을 수행했습니다.
IApplicationThread는 시스템 프로세스에만 전달되어야 하지만, 예기치 않게 system_server 외부로 전송될 수 있습니다.
아무도 모든 사람에게 노출된 getIApplicationThreadForApp(String packageName) API를 구현하지 않을 것입니다. 이는 명백한 보안 위반입니다.
하지만 IApplicationThread가 다른 객체에 래핑되어 외부 래퍼 객체가 전송된다면 더 가능성 있는 시나리오입니다.
RemoteTransition은 애니메이션을 실행 중인 앱의 우선순위를 높이기 위해 IApplicationThread를 포함하는 그러한 래퍼입니다.
해당 API의 사용자 중 하나는 AOSP 및 Pixel 기기의 기본 홈 애플리케이션인 Launcher3로, RemoteTransition을 사용하여 ActivityOptions를 생성한 다음 startActivity()에 전달합니다.
Launcher3 자체는 신뢰할 수 없는 요소에 객체를 노출하지 않지만, system_server는 때때로 노출합니다.
CVE-2022-20419는 system_server가 호출자가 전달한 ActivityOptions를 실행된 앱에 전달하면서 RemoteTransition을 제거하는 것을 잊어버려, 실행된 앱이 이를 수신하고 런처 프로세스 내에서 임의 코드를 로드할 수 있게 되어 발생했습니다.
공유 요소 전환 애니메이션 중에는 많은 작업이 수행되어야 하며 WMCore와 WMShell 간에 통신이 필요합니다. 여기서 WM은 Window Manager를 의미합니다.
WMShell을 이해하려면 이 문서를 읽을 수 있습니다.
WMCore와 WMShell은 서로 다른 프로세스에서 실행되므로(WMCore는 system_server에서, WMShell은 SystemUI에서 실행), 서로 통신하기 위해 Binder 메커니즘을 활용합니다.
WMCore는 Binder registerTransitionPlayer API를 노출했고, WMShell은 이를 사용하여 자체 Binder를 등록합니다.
애니메이션이 시작되면 WMCore는 requestStartTransition을 호출하고 TransitionRequestInfo가 원격으로 전달되며, 여기에는 초기 RemoteTransition이 포함됩니다.
따라서 전환 플레이어를 교체할 수 있다면 Launcher의 IApplicationThread를 검색하고 권한 있는 프로세스 내에서 임의 코드 실행을 달성할 수 있습니다.
그러나 registerTransitionPlayer는 MANAGE_ACTIVITY_TASKS 권한으로 보호되며, 타사 앱은 이 권한을 얻을 수 없습니다.
하지만 adb shell도 신뢰할 수 없는 사용자 코드를 실행할 수 있으며, 셸에는 MANAGE_ACTIVITY_TASKS 권한이 부여되어 있으므로, 운 좋게도 adb 셸에서 공격을 시작할 수 있습니다.
공격자가 이 취약점을 통해 무엇을 할 수 있는지는 재미있는 질문입니다.
Launcher에 부여된 대부분의 권한은 adb 셸도 보유하고 있으므로, 이미 셸 ID로 코드를 실행할 수 있는 공격자는 기기를 손상시키기 위해 이 취약점을 악용할 필요가 없습니다.
이것은 악성 앱이 사용할 수 있는 익스플로잇보다 IApplicationThread를 학습하기 위한 교육용 예제 프로젝트에 더 가깝습니다.
하지만 일부 사람들은 여전히 이것에 관심이 있을 수 있습니다.
예를 들어, Launcher의 개인 파일을 추출하는 데 사용할 수 있으며, 이는 기기를 루팅하지 않고 악성 Launcher 앱에 대한 포렌식 분석에 유용할 수 있습니다. 이전에는 CVE-2024-31317을 악용하여 이를 달성했으며, 내 발견은 이전 방법이 수정된 후 또 다른 방법을 제시합니다.
또한 사용자는 기기를 먼저 루팅하지 않고도 Fabricated Runtime Resources Overlay (FRRO)를 사용할 수 있습니다. 따라서 CVE-2021-39630이 패치된 후 루트리스 맞춤 테마가 돌아왔습니다. 내 익스플로잇은 android:integer/config_multiuserMaximumUsers를 100으로 설정하여 이를 입증했습니다.
또한 Launcher는 기본적으로 Recents 화면 구성요소도 호스팅하므로 일부 권한 있는 작업에 대해 허용 목록에 포함됩니다. Launcher는 실행된 Activity의 exported/권한 설정에 관계없이 기존 태스크에서 임의의 Activity를 시작할 수 있으며, 이는 일부 기기 관리 도구 앱에서 원할 수 있지만, 저는 직접 테스트하지 않았습니다.
프로젝트를 빌드하고 생성된 apk 파일을 설치합니다(Android Studio 내에서 실행 버튼을 사용하는 경우 'Always install with package manager'를 켜십시오).
PC에서 다음 명령을 실행합니다.
adb shell app_process '-Djava.class.path=$(pm path top.canyie.transitionplayer | cut -c9-) /system/bin top.canyie.transitionplayer.Main'
그런 다음 런처에서 아이콘을 탭하여 임의의 앱을 시작합니다.
런처 앱에서 알림이 전송되어야 하며, Android 14+를 사용 중이라면 조작된 오버레이가 시스템에 주입되어 adb shell cmd overlay lookup android android:integer/config_multiuserMaximumUsers가 100을 반환해야 합니다.