canyie/transitionplayerCVE-2026-0091, Androidのウィンドウ管理の脆弱性を利用して、adbからLauncherプロセスで任意のコード実行を行う。
この問題は、2026年6月のAndroidセキュリティ情報でAndroid 14+向けに修正されました。パッチはこちらをクリック
TODO
時間ができたらwriteupを完成させます
でもその前に学校の課題と試験と戦わないといけません
試験が終わる前にセクションを完成させることにしました
自分に幸運を祈ります 😇
IApplicationThreadは、システムがアプリにコマンドを送信するために使用するプライベートコールバックです（指定されたアプリのロード、コンポーネントライフサイクルの変更通知など）。
これはシステムからのみ使用可能であることを意図しており、権限チェックは存在しません。セキュリティは、悪意のあるプロセスによってオブジェクトが取得されないという事実のみによって保証されています。これはWebにおける「クッキー」や「トークン」の概念に似ています。このようなアクセス制御モデルはCapability-based Securityと呼ばれます。
もし誰かが他のプロセスからIApplicationThreadを取得できた場合、任意のコマンドを送信でき、被害アプリはシステムが生成したかのように偽造コマンドを処理します。CVE-2022-20452の以前の脆弱性では、この手法が任意のコード実行に使用されました。
IApplicationThreadはシステムプロセスにのみ渡されるべきですが、予期せずsystem_serverの外部に送信される可能性があります。
だれもgetIApplicationThreadForApp(String packageName)のようなAPIを実装して外部に公開することはありません。それは明らかなセキュリティ違反です。
しかし、もしIApplicationThreadが別のオブジェクトにラップされ、その外側のラッパーオブジェクトが送信される場合、より可能性の高いシナリオです。
RemoteTransitionはそのようなラッパーであり、アニメーションを実行しているアプリの優先度を上げるためにIApplicationThreadを含んでいます。
このAPIの利用者の1つはLauncher3で、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 shellから攻撃を仕掛けることができます。
この脆弱性を通じて攻撃者が何ができるかというのは興味深い疑問です。
Launcherに付与されているほとんどの権限はadb shellも保持しているため、すでにシェルIDでコードを実行できる攻撃者はデバイスを侵害するためにこの脆弱性を悪用する必要はありません。
これは、悪意のあるアプリが使用できるエクスプロイトというよりも、IApplicationThreadを学ぶための教育的なサンプルプロジェクトです。
しかし、これに興味を持つ人もいるかもしれません。
例えば、Launcherのプライベートファイルを抽出するために使用できます。これは、デバイスをroot化せずに悪意のあるLauncherアプリのフォレンジック分析に役立つ可能性があります。以前はCVE-2024-31317を悪用することで実現されていましたが、私の発見は以前のものが修正された後の別の方法を明らかにします。
また、ユーザーはFabricated Runtime Resources Overlay (FRRO)をデバイスをroot化せずに使用できるようになります。これにより、CVE-2021-39630が修正された後、root化不要のカスタムテーマが復活します。私のエクスプロイトでは、android:integer/config_multiuserMaximumUsersを100に設定することでこれを実証しています。
さらに、LauncherはデフォルトでRecents画面コンポーネントもホストしており、そのため一部の特権アクションに対してホワイトリスト登録されています。Launcherは、起動されるアクティビティのエクスポート/権限設定に関係なく、既存のタスク内で任意のアクティビティを開始できると考えられます。これは一部のデバイス管理ツールアプリが望む機能かもしれませんが、私は自分でテストしていません。
プロジェクトをビルドし、生成された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を返すはずです。