
Analyse et preuve de concept ADB pour CVE-2026-20516, une faille de type confused deputy dans MediaTek Android TV MiracastService permettant des changements locaux d'état Wi-Fi Direct.
Recherche et divulgation par Davide Di Matteo (@Dingo97).
Il s'agit de mon premier CVE crédité. J'ai découvert un service Miracast privilégié système, exporté de manière incorrecte, lors de mes recherches sur un téléviseur Android TV PEAQ. Un appelant peut fournir un extra d'intent qui amène le service à modifier l'état du Wi-Fi Direct en utilisant ses propres privilèges.
MediaTek a publié le problème dans son bulletin de sécurité de septembre 2026 et crédite Davide Di Matteo dans ses remerciements de sécurité. Cet article et la reproduction ADB originale sont publiés à la suite d'une divulgation coordonnée et avec l'autorisation du fournisseur.
Lire sur mon site web · Dépôt GitHub
| Champ | Valeur |
|---|---|
| CVE | CVE-2026-20516 |
| Composant | com.mediatek.androidbox.MiracastService |
| Sévérité du fournisseur | Moyenne |
| CVSS v3.1 publié | 5.5 — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (Tenable) |
| Faiblesse officielle | CWE-926 : Exportation incorrecte de composants d'application Android |
| Mécanisme | Confused deputy / contrôle d'accès manquant |
| Impact décrit par le fournisseur | Déni de service local via une possible élévation de privilèges |
| Prérequis d'attaque | Exécution de code local avec privilèges utilisateur ; aucune interaction utilisateur requise |
| Identifiants de correctif | ALPS11060069 / DTV04881615 |
| Problème MediaTek | MSV-7882 |
| Publication du fournisseur | 7 septembre 2026 |
| Publication de l'article | 11 septembre 2026 |
L'impact, les identifiants de correctif et les prérequis d'attaque locale sont documentés dans l'enregistrement CVE. Le score numérique et le vecteur ci-dessus sont ceux publiés par Tenable. Ils remplacent l'évaluation préliminaire de 5.1 figurant dans mon rapport original. CWE-284 (contrôle d'accès incorrect) et CWE-441 (confused deputy) décrivent l'analyse originale ; MediaTek classe le problème comme CWE-926.
| Champ | Valeur |
|---|---|
| Appareil | PEAQ Smart TV, modèle AI PONT |
| OEM / plateforme | Changhong / MediaTek |
| Système d'exploitation | Android TV 11 |
| Niveau de correctif de sécurité Android | Juin 2025 |
| Build | RTMA.250416.192 |
| Noyau | 4.19.116++ (#1 Sat Aug 23 09:58:11 CST 2025) |
| Logiciel | V03.06037 |
| Paquet | com.mediatek.androidbox |
| APK | WFDSinkTest_CH.apk |
| Version de l'application | 1.0.0.16 |
| UID partagé déclaré | android.uid.system |
Il s'agit des détails de l'appareil utilisé pour la recherche originale, et non d'une liste de toutes les versions de firmware vulnérables ou corrigées.
L'analyse du manifeste consignée dans le rapport original montre que MiracastService est exporté avec android:exported="true", sans permission protégeant l'accès au service. L'application déclare android:sharedUserId="android.uid.system".
La méthode onStartCommand() du service lit l'extra d'intent booléen screen_share sans vérifier si l'appelant est autorisé à contrôler Miracast. Le service effectue ensuite des opérations dans son propre contexte privilégié. C'est le confused deputy : l'appelant fournit la requête, tandis que le service système fournit l'autorité.
Dans l'implémentation analysée, le chemin screen_share=false peut appeler WifiP2pManager.createGroup(). L'appel est conditionnel : le partage d'écran doit être désactivé dans l'état du service, le Wi-Fi P2P doit être activé, et aucun groupe ne doit déjà exister. Le nom du booléen ne doit pas être interprété comme une affirmation directe indiquant si un groupe sera créé ou supprimé.
Le rapport consigne également une écriture vers Settings.Global.putInt(..., "miracast_enable", 1) dans onCreate(). Le déclenchement du cycle de vie du service peut donc provoquer une écriture dans les paramètres protégés via le service. Il s'agit d'une observation issue de l'analyse de l'implémentation ; l'extrait de journal ci-dessous ne démontre pas cette écriture de manière indépendante.
Les vérifications de permissions pertinentes dépendent du framework Android et du build OEM. Le problème clé est l'autorisation manquante à la frontière du service exporté, plutôt que l'affirmation selon laquelle chaque version d'Android applique un ensemble de permissions identique pour le Wi-Fi Direct.
MediaTek décrit un risque de déni de service local. Sur le téléviseur testé, la session ADB enregistrée montre le service acceptant screen_share=false et créant avec succès un groupe Wi-Fi Direct. Des modifications inattendues de cet état peuvent interférer avec l'utilisation légitime de Miracast et peuvent exposer un état de récepteur que l'utilisateur n'a pas demandé.
Le composant exporté et le contrôle d'accès manquant étayent un chemin d'attaque par application locale dans l'analyse originale. Le shell ADB s'exécute sous l'identité shell Android, et non sous un UID d'application ordinaire. Par conséquent, ces commandes et journaux démontrent le comportement du service depuis ADB ; ils ne prouvent pas, à eux seuls, une exécution depuis une application sans permissions. Ce dépôt n'inclut pas de reproduction basée sur une application testée séparément.
L'extrait n'établit pas d'exécution de code arbitraire, de shell root, de connexion établie depuis un appareil à proximité, ni de suppression réussie de groupe. L'appelant n'acquiert pas l'UID système du service ; il amène le service à agir en son nom.
Ce qui suit est la reproduction manuelle issue du rapport original. Elle modifie l'état de Miracast et force l'arrêt du paquet récepteur. Enregistrez l'état de diffusion actuel avant de l'exécuter.
Dans le premier terminal :
adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'
Dans le second 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
Il s'agit de la séquence de réinitialisation utilisée dans la reproduction originale. Un force-stop de paquet ne garantit pas que le sous-système Wi-Fi d'Android a supprimé un groupe existant. Si un groupe persiste, réinitialisez le récepteur via les commandes du téléviseur et vérifiez son état avant de réessayer.
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false
Recherchez Enter createGroup suivi de createGroup success. Si seul Received screen_share tag apparaît, l'intent a été traité, mais la création du groupe n'a pas été démontrée : vérifiez les préconditions décrites ci-dessus.
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true