CVE-2026-20516: MiracastService Confused Deputy auf Android TV

Recherche und Offenlegung durch Davide Di Matteo (@Dingo97).

Dies ist meine erste anerkannte CVE. Ich habe einen unsachgemäß exportierten, systemprivilegierten Miracast-Dienst während der Recherche an einem PEAQ Android TV entdeckt. Ein Aufrufer kann ein Intent-Extra übergeben, das den Dienst dazu bringt, den Wi-Fi Direct-Status mit seinen eigenen Privilegien zu ändern.

MediaTek hat das Problem in seinem Sicherheitsbulletin vom September 2026 veröffentlicht und Davide Di Matteo in seinen Sicherheitsdanksagungen genannt. Dieser Bericht und die ursprüngliche ADB-Reproduktion werden nach koordinierter Offenlegung und mit Genehmigung des Herstellers veröffentlicht.

Auf meiner Website lesen · GitHub-Repository

Zusammenfassung der Schwachstelle

Die Auswirkung, Patch-Identifikatoren und lokalen Angriffsvoraussetzungen sind im CVE-Eintrag dokumentiert. Der numerische Score und der Vektor oben sind die von Tenable veröffentlichten. Sie ersetzen die vorläufige Bewertung von 5.1 in meinem ursprünglichen Bericht. CWE-284 (unsachgemäße Zugriffskontrolle) und CWE-441 (Confused Deputy) beschreiben die ursprüngliche Analyse; MediaTek klassifiziert das Problem als CWE-926.

Getestete Umgebung

Dies sind die Details des für die ursprüngliche Recherche verwendeten Geräts, keine Liste aller anfälligen oder behobenen Firmware-Versionen.

Grundursache

Die im ursprünglichen Bericht dokumentierte Manifest-Analyse zeigt, dass MiracastService mit android:exported="true" exportiert wird, ohne eine Berechtigung, die den Zugriff auf den Dienst schützt. Die Anwendung deklariert android:sharedUserId="android.uid.system".

Die onStartCommand() des Dienstes liest das boolesche Intent-Extra screen_share, ohne zu prüfen, ob der Aufrufer zur Steuerung von Miracast berechtigt ist. Der Dienst führt dann Operationen in seinem eigenen privilegierten Kontext aus. Dies ist der Confused Deputy: Der Aufrufer liefert die Anfrage, während der Systemdienst die Autorität liefert.

In der analysierten Implementierung kann der Pfad screen_share=false WifiP2pManager.createGroup() aufrufen. Der Aufruf ist bedingt: Screen Sharing muss im Zustand des Dienstes deaktiviert sein, Wi-Fi P2P muss aktiviert sein und es darf noch keine Gruppe existieren. Der Name des Booleschen Werts sollte nicht als direkte Aussage darüber interpretiert werden, ob eine Gruppe erstellt oder entfernt wird.

Der Bericht dokumentiert außerdem einen Schreibvorgang auf Settings.Global.putInt(..., "miracast_enable", 1) in onCreate(). Das Auslösen des Dienst-Lebenszyklus kann daher einen Schreibvorgang auf geschützte Einstellungen über den Dienst verursachen. Dies ist eine Beobachtung aus der Implementierungsanalyse; der untenstehende Log-Auszug belegt diesen Schreibvorgang nicht unabhängig.

Die relevanten Berechtigungsprüfungen hängen vom Android-Framework und dem OEM-Build ab. Das Kernproblem ist die fehlende Autorisierung an der Grenze des exportierten Dienstes, nicht die Behauptung, dass jede Android-Version einen identischen Berechtigungssatz für Wi-Fi Direct durchsetzt.

Auswirkung und Evidenzgrenzen

MediaTek beschreibt ein lokales Denial-of-Service-Risiko. Auf dem getesteten TV zeigt die aufgezeichnete ADB-Sitzung, dass der Dienst screen_share=false akzeptiert und erfolgreich eine Wi-Fi Direct-Gruppe erstellt. Unerwartete Änderungen dieses Zustands können die legitime Miracast-Nutzung beeinträchtigen und möglicherweise einen Empfängerzustand offenlegen, den der Benutzer nicht angefordert hat.

Die exportierte Komponente und die fehlende Zugriffskontrolle stützen in der ursprünglichen Analyse einen Angriffspfad über eine lokale App. ADB Shell läuft als Android-Shell-Identität, nicht als gewöhnliche Anwendungs-UID. Folglich demonstrieren diese Befehle und Logs das Dienstverhalten von ADB aus; sie beweisen für sich genommen nicht die Ausführung aus einer Anwendung ohne Berechtigungen. Dieses Repository enthält keine separat getestete anwendungsbasierte Reproduktion.

Der Auszug belegt keine beliebige Codeausführung, keine Root-Shell, keine abgeschlossene Verbindung von einem nahegelegenen Gerät oder eine erfolgreiche Gruppenentfernung. Der Aufrufer erlangt nicht die System-UID des Dienstes; er veranlasst den Dienst, in seinem Namen zu handeln.

Proof of Concept

Voraussetzungen

• Die getestete anfällige Firmware oder ein gleichwertiger Build, der dieselbe Komponente exponiert.
• ADB auf dem Host installiert und eine autorisierte Debugging-Verbindung zu einem TV, den Sie besitzen oder für den Sie zur Testung autorisiert sind.
• Wi-Fi und Wi-Fi Direct auf dem TV verfügbar.
• Zwei Terminals. Die folgenden Host-Befehle verwenden eine POSIX-Shell, zum Beispiel Bash oder WSL mit Zugriff auf ADB.

Das Folgende ist die manuelle Reproduktion aus dem ursprünglichen Bericht. Sie ändert den Miracast-Status und erzwingt das Beenden des Empfängerpakets. Zeichnen Sie den aktuellen Casting-Status auf, bevor Sie sie ausführen.

1. Den Dienst überwachen

Im ersten Terminal:

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

2. Den Empfängerzustand vorbereiten

Im zweiten Terminal:

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

Dies ist die in der ursprünglichen Reproduktion verwendete Reset-Sequenz. Ein Paket-Force-Stop garantiert nicht, dass das Android-Wi-Fi-Subsystem eine bestehende Gruppe entfernt hat. Wenn eine Gruppe bestehen bleibt, setzen Sie den Empfänger über die Steuerelemente des TVs zurück und überprüfen Sie seinen Zustand, bevor Sie es erneut versuchen.

3. Gruppenerstellung anfordern

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

Achten Sie auf Enter createGroup, gefolgt von createGroup success. Wenn nur Received screen_share tag erscheint, wurde der Intent verarbeitet, aber die Gruppenerstellung wurde nicht nachgewiesen: Prüfen Sie die oben beschriebenen Vorbedingungen.

4. Bereinigung anfordern und den TV überprüfen

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

Dies sendet den im ursprünglichen Bericht verwendeten Bereinigungswert. Überprüfen Sie mit den Steuerelementen des TVs, dass Casting und Wi-Fi Direct in den beabsichtigten Zustand zurückgekehrt sind. Der bloße Empfang des Intents ist kein Beweis dafür, dass die Bereinigung erfolgreich war; stellen Sie den Empfänger bei Bedarf manuell wieder her.

Erfasste Evidenz

Der folgende logcat-Auszug wurde am 10. März 2026 auf dem getesteten TV erfasst. Er ist Evidenz aus der ursprünglichen Recherche, kein für diese Veröffentlichung durchgeführter neuer Test.

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

Die ersten drei Zeilen zeigen den Parameterempfang, den Eintritt in den Pfad zur Gruppenerstellung und einen erfolgreichen Callback. Die letzte Zeile zeigt den Empfang von true; sie enthält keinen Callback für eine erfolgreiche Entfernung. PID 30288 ist sichtbar, aber die Prozess-UID und die Aufruferidentität sind in diesem Auszug nicht aufgezeichnet.

Betroffener Umfang

Meine Reproduktion ist auf die obige PEAQ AI PONT-Konfiguration beschränkt. Das Bulletin von MediaTek listet betroffene Chipsätze über dieses Gerät hinaus auf; konsultieren Sie den CVE-2026-20516-Eintrag des Herstellers für den maßgeblichen Umfang. Die Aufnahme eines Chipsatzes identifiziert nicht, ob ein bestimmter Einzelhandels-TV seinen OEM-Firmware-Fix erhalten hat.

Die Paket- und APK-Benennung deutete während der ursprünglichen Recherche auf eine gemeinsame MediaTek/Changhong-Komponente hin. Diese Beobachtung allein belegt nicht das Vorhandensein dieses exportierten Dienstes auf jedem MediaTek-basierten TV.

Behebung

Gerätebesitzer sollten Firmware mit dem relevanten Fix von ihrem TV-Hersteller beziehen. MediaTek identifiziert die Fixes als ALPS11060069 / DTV04881615; im Rahmen dieses Berichts wurde keine behobene PEAQ-Firmware-Version verifiziert.

Für Maintainer der Komponente: Entfernen Sie die externe Exposition mit android:exported="false", wenn externe Aufrufer nicht erforderlich sind. Wenn ein vertrauenswürdiger anwendungsübergreifender Zugriff erforderlich ist, schützen Sie den Dienst mit einer geeigneten Berechtigung auf Signatur-Ebene und erzwingen Sie die Autorisierung, bevor der Empfängerzustand geändert wird. Überprüfen Sie alle Einstiegspunkte und Lebenszyklus-Nebeneffekte, einschließlich Schreibvorgängen auf geschützte Einstellungen.

Dies sind Härtungsempfehlungen aus der Analyse, keine Beschreibung des unveröffentlichten Hersteller-Patches. Validieren Sie das Ergebnis sowohl mit einer gewöhnlichen Anwendungs-UID als auch mit legitimen Casting-Clients.

Offenlegungs-Zeitplan und Anerkennung

Entdeckt und gemeldet von Davide Di Matteo. Danke an MediaTek für die Koordinierung der Offenlegung und die Anerkennung der Recherche in den Danksagungen vom September 2026.

Referenzen

• MediaTek — Sicherheitsbulletin September 2026
• MediaTek — Sicherheitsdanksagungen
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516