CVE-2026-20516: Android TV における MiracastService の混乱した代理（confused deputy）

Davide Di Matteo (@Dingo97) による調査および開示。

これは私にとって初めてクレジットされた CVE です。PEAQ Android TV を調査中に、不適切にエクスポートされたシステム権限の Miracast サービスを発見しました。呼び出し元は、サービス自身の権限を使って Wi-Fi Direct の状態を変更させる intent extra を供給できます。

MediaTek はこの問題を 2026年9月のセキュリティ速報 で公開し、セキュリティ謝辞 で Davide Di Matteo をクレジットしています。この記事と元の ADB 再現手順は、協調的開示とベンダーの許可を得た上で公開されています。

私のウェブサイトで読む · GitHub リポジトリ

脆弱性の概要

影響、パッチ識別子、ローカル攻撃の前提条件は CVE レコード に記載されています。上記の数値スコアとベクターは Tenable が公開したものです。これらは私の元の報告における暫定的な 5.1 の評価を置き換えるものです。CWE-284（不適切なアクセス制御）と CWE-441（混乱した代理）は元の分析を説明するものであり、MediaTek はこの問題を CWE-926 として分類しています。

検証済み環境

これらは元の調査に使用されたデバイスの詳細であり、脆弱な、または修正済みのすべてのファームウェアバージョンの一覧ではありません。

根本原因

元の報告に記録されたマニフェスト分析によると、MiracastService は android:exported="true" でエクスポートされており、サービスへのアクセスを保護するパーミッションがありません。アプリケーションは android:sharedUserId="android.uid.system" を宣言しています。

サービスの onStartCommand() は、呼び出し元が Miracast を制御する権限を持っているかを確認せずに、boolean 型の screen_share intent extra を読み取ります。その後、サービスは自身の特権コンテキストで操作を実行します。これが混乱した代理です。呼び出し元がリクエストを供給し、システムサービスが権限を供給します。

分析された実装では、screen_share=false のパスが WifiP2pManager.createGroup() を呼び出す可能性があります。この呼び出しは条件付きです。サービスの状態で画面共有が無効になっていること、Wi-Fi P2P が有効になっていること、そしてグループがまだ存在しないことが必要です。この boolean の名前は、グループが作成または削除されるかどうかについての直接的な記述として解釈されるべきではありません。

報告にはまた、onCreate() 内で Settings.Global.putInt(..., "miracast_enable", 1) への書き込みが記録されています。したがって、サービスのライフサイクルをトリガーすると、サービスを通じて保護された設定の書き込みが発生する可能性があります。これは実装分析からの観察であり、以下のログ抜粋はその書き込みを独立して実証するものではありません。

関連するパーミッションチェックは Android フレームワークと OEM ビルドに依存します。重要な問題は、すべての Android バージョンが Wi-Fi Direct に対して同一のパーミッションセットを強制するという主張ではなく、エクスポートされたサービスの境界における認可の欠如です。

影響と証拠の範囲

MediaTek はローカルサービス拒否のリスクを説明しています。検証済みの TV では、記録された ADB セッションは、サービスが screen_share=false を受け入れ、Wi-Fi Direct グループの作成に成功したことを示しています。この状態への予期しない変更は、正当な Miracast の使用を妨害し、ユーザーが要求していないレシーバー状態を露出させる可能性があります。

エクスポートされたコンポーネントとアクセス制御の欠如は、元の分析においてローカルアプリによる攻撃経路を裏付けています。ADB シェルは Android の shell アイデンティティとして実行され、通常のアプリケーション UID としては実行されません。 したがって、これらのコマンドとログは ADB からのサービス動作を実証するものであり、それ自体ではゼロパーミッションのアプリケーションからの実行を証明するものではありません。このリポジトリには、別途検証されたアプリケーションベースの再現は含まれていません。

この抜粋は、任意のコード実行、root シェル、近くのデバイスからの接続完了、またはグループ削除の成功を立証するものではありません。呼び出し元はサービスのシステム UID を取得するのではなく、サービスに自身の代理として動作させるのです。

概念実証

前提条件

• 検証済みの脆弱なファームウェア、または同じコンポーネントを露出する同等のビルド。
• ホストにインストールされた ADB と、所有している、または検証を許可された TV への認可されたデバッグ接続。
• TV で利用可能な Wi-Fi および Wi-Fi Direct。
• 2 つのターミナル。以下のホストコマンドは POSIX シェル（例えば Bash、または ADB にアクセスできる WSL）を使用します。

以下は元の報告からの手動再現です。Miracast の状態を変更し、レシーバーパッケージを強制停止します。実行前に現在のキャスト状態を記録してください。

1. サービスの監視

最初のターミナルで:

adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'

2. レシーバー状態の準備

2 番目のターミナルで:

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true
sleep 3
adb shell am force-stop com.mediatek.androidbox
sleep 2

これは元の再現で使用されたリセットシーケンスです。パッケージの強制停止は、Android Wi-Fi サブシステムが既存のグループを削除したことを保証するものではありません。グループが残っている場合は、TV のコントロールを通じてレシーバーをリセットし、再試行する前にその状態を確認してください。

3. グループ作成の要求

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false

Enter createGroup に続いて createGroup success を探してください。Received screen_share tag のみが表示される場合、intent は処理されましたが、グループ作成は実証されていません。上記の前提条件を確認してください。

4. クリーンアップの要求と TV の確認

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true

これは元の報告で使用されたクリーンアップ値を送信します。TV のコントロールを使用して、キャストと Wi-Fi Direct が意図した状態に戻ったことを確認してください。intent の受信だけではクリーンアップが成功した証拠にはなりません。必要に応じてレシーバーを手動で復元してください。

取得された証拠

以下の logcat 抜粋は、2026年3月10日 に検証済みの TV で取得されました。これは元の調査からの証拠であり、この公開のために実施された新しいテストではありません。

03-10 19:40:27.458 30288 30288 I MiracastService: Received screen_share tag: false
03-10 19:40:27.460 30288 30288 D MiracastService:  Enter createGroup
03-10 19:40:27.530 30288 30288 D MiracastService:  createGroup success
03-10 19:41:19.148 30288 30288 I MiracastService: Received screen_share tag: true

最初の 3 行は、パラメータの受信、グループ作成パスへの進入、およびコールバックの成功を示しています。最後の行は true の受信を示していますが、削除成功のコールバックは含まれていません。PID 30288 は確認できますが、プロセス UID と呼び出し元のアイデンティティはこの抜粋には記録されていません。

影響範囲

私の再現は上記の PEAQ AI PONT 構成に限定されています。MediaTek の速報はそのデバイス以外の影響を受けるチップセットを列挙しています。権威ある範囲については ベンダーの CVE-2026-20516 エントリ を参照してください。チップセットの記載は、特定の市販 TV が OEM ファームウェア修正を受け取ったかどうかを特定するものではありません。

パッケージと APK の命名は、元の調査中に MediaTek/Changhong の共有コンポーネントを示唆していました。その観察だけでは、すべての MediaTek ベースの TV にこのエクスポートされたサービスが存在することを立証するものではありません。

修復

デバイス所有者は、TV メーカーから関連する修正を含むファームウェアを入手すべきです。MediaTek は修正を ALPS11060069 / DTV04881615 として識別しています。この記事の一部として修正済みの PEAQ ファームウェアバージョンは検証されていません。

コンポーネントのメンテナーは、外部呼び出し元が不要な場合は android:exported="false" で外部への露出を削除してください。信頼されたアプリケーション間アクセスが必要な場合は、適切な署名レベルのパーミッションでサービスを保護し、レシーバー状態を変更する前に認可を強制してください。保護された設定の書き込みを含む、すべてのエントリポイントとライフサイクルの副作用をレビューしてください。

これらは分析からのハードニング推奨事項であり、未公開のベンダーパッチの説明ではありません。通常のアプリケーション UID と正当なキャストクライアントの両方を使用して結果を検証してください。

開示タイムラインとクレジット

Davide Di Matteo によって発見および報告されました。 開示を調整し、2026年9月のクレジット で調査を称えた MediaTek に感謝します。

参考文献

• MediaTek — 2026年9月セキュリティ速報
• MediaTek — セキュリティ謝辞
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516