CVE-2026-20516 : Confused deputy dans MiracastService sur Android TV

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

Résumé de la vulnérabilité

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.

Environnement testé

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.

Cause racine

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.

Impact et limites des preuves

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.

Preuve de concept

Prérequis

• Le firmware vulnérable testé, ou un build équivalent exposant le même composant.
• ADB installé sur l'hôte et une connexion de débogage autorisée vers un téléviseur que vous possédez ou êtes autorisé à tester.
• Wi-Fi et Wi-Fi Direct disponibles sur le téléviseur.
• Deux terminaux. Les commandes hôte ci-dessous utilisent un shell POSIX, par exemple Bash ou WSL avec accès à ADB.

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.

1. Surveiller le service

Dans le premier terminal :

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

2. Préparer l'état du récepteur

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.

3. Demander la création du groupe

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.

4. Demander le nettoyage et vérifier le téléviseur

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

Cela envoie la valeur de nettoyage utilisée dans le rapport original. Vérifiez que la diffusion et le Wi-Fi Direct sont revenus à l'état souhaité à l'aide des commandes du téléviseur. La seule réception de l'intent ne prouve pas que le nettoyage a réussi ; restaurez le récepteur manuellement si nécessaire.

Preuves capturées

L'extrait logcat suivant a été capturé sur le téléviseur testé le 10 mars 2026. Il s'agit d'une preuve issue de la recherche originale, et non d'un nouveau test réalisé pour cette publication.

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

Les trois premières lignes montrent la réception du paramètre, l'entrée dans le chemin de création de groupe et un callback réussi. La dernière ligne montre la réception de true ; elle n'inclut pas de callback de succès de suppression. Le PID 30288 est visible, mais l'UID du processus et l'identité de l'appelant ne sont pas enregistrés dans cet extrait.

Périmètre affecté

Ma reproduction est limitée à la configuration PEAQ AI PONT ci-dessus. Le bulletin de MediaTek liste des chipsets affectés au-delà de cet appareil ; consultez l'entrée CVE-2026-20516 du fournisseur pour le périmètre faisant autorité. L'inclusion d'un chipset n'indique pas si un téléviseur de détail particulier a reçu son correctif firmware OEM.

Le nommage du paquet et de l'APK suggérait un composant partagé MediaTek/Changhong lors de la recherche originale. Cette observation seule n'établit pas la présence de ce service exporté sur chaque téléviseur basé sur MediaTek.

Remédiation

Les propriétaires d'appareils doivent obtenir un firmware contenant le correctif pertinent auprès du fabricant de leur téléviseur. MediaTek identifie les correctifs comme ALPS11060069 / DTV04881615 ; aucune version de firmware PEAQ corrigée n'a été vérifiée dans le cadre de cet article.

Pour les mainteneurs du composant, supprimez l'exposition externe avec android:exported="false" si les appelants externes ne sont pas nécessaires. Si un accès inter-applications de confiance est requis, protégez le service avec une permission de niveau signature appropriée et appliquez l'autorisation avant de modifier l'état du récepteur. Examinez tous les points d'entrée et effets de bord du cycle de vie, y compris les écritures dans les paramètres protégés.

Il s'agit de recommandations de durcissement issues de l'analyse, et non d'une description du correctif fournisseur non publié. Validez le résultat en utilisant un UID d'application ordinaire ainsi que des clients de diffusion légitimes.

Chronologie de divulgation et crédit

Découvert et signalé par Davide Di Matteo. Merci à MediaTek pour la coordination de la divulgation et la reconnaissance de la recherche dans ses crédits de septembre 2026.

Références

• MediaTek — Bulletin de sécurité de septembre 2026
• MediaTek — Remerciements de sécurité
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516