Panoramica
Analizzando una smart TV PEAQ con Android TV, ho individuato un servizio Miracast accessibile dall’esterno senza un controllo adeguato delle autorizzazioni. Il servizio opera con privilegi di sistema: chi lo richiama può passargli un parametro nell’intent e indurlo a modificare lo stato del Wi-Fi Direct usando quei privilegi.
MediaTek ha inserito la vulnerabilità nel bollettino di sicurezza di settembre 2026 e ha riconosciuto il contributo di Davide Di Matteo nella pagina dei riconoscimenti ai ricercatori. L’analisi e il test originale via ADB sono stati pubblicati al termine della disclosure coordinata, con l’approvazione del produttore.
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. Il
valore sostituisce la stima preliminare di 5.1 riportata nella
segnalazione privata.
La richiesta, passo dopo passo
Di chi sono i privilegi?
Il diagramma segue la richiesta del test originale via ADB. Seleziona un passaggio per vedere cosa accade.
1. La richiesta parte da ADB
Nel test documentato, il comando ADB avvia MiracastService
passando il parametro screen_share. La richiesta
proviene dalla shell di Android. Questo test non documenta
l’esecuzione da una normale applicazione.
2. Manca il controllo delle autorizzazioni
Il servizio accetta il parametro senza verificare se chi lo invia sia autorizzato a controllare Miracast. L’applicazione dichiara l’UID condiviso di sistema: il chiamante può quindi influenzare operazioni che il servizio esegue con privilegi superiori ai suoi.
3. Il servizio agisce con i propri privilegi
Quando si verificano le condizioni descritte nel test, il
servizio chiama WifiP2pManager.createGroup(). Il
callback registrato nel log conferma la creazione del gruppo
Wi-Fi Direct. Chi ha inviato la richiesta non ottiene un UID
di sistema né una shell root.
Riepilogo della vulnerabilità
| CVE | CVE-2026-20516 |
|---|---|
| Componente |
com.mediatek.androidbox.MiracastService
|
| Gravità secondo MediaTek | Media |
| Classificazione ufficiale | CWE-926: esportazione impropria di componenti applicativi Android |
| Meccanismo | Confused deputy: manca la verifica delle autorizzazioni |
| Impatto descritto da MediaTek | Denial of service locale dovuto a una possibile escalation di privilegi |
| Prerequisiti dell'attacco | Esecuzione di codice sul dispositivo con privilegi utente, senza interazione da parte dell’utente |
| Identificativi delle patch |
ALPS11060069 / DTV04881615
|
| Segnalazione MediaTek | MSV-7882 |
| Pubblicazione del bollettino | 7 settembre 2026 |
| Pubblicazione dell'analisi | 11 settembre 2026 |
Ambiente di prova
| Dispositivo | Smart TV PEAQ, modello AI PONT |
|---|---|
| OEM / piattaforma | Changhong / MediaTek |
| Sistema operativo | Android TV 11 |
| Livello delle patch di sicurezza | Giugno 2025 |
| Build | RTMA.250416.192 |
| Kernel | 4.19.116++ |
| Software | V03.06037 |
| Pacchetto | com.mediatek.androidbox |
| APK | WFDSinkTest_CH.apk |
| Versione dell'applicazione | 1.0.0.16 |
| Shared UID dichiarato | android.uid.system |
Queste informazioni descrivono il dispositivo usato per la ricerca. Non sono un elenco completo dei firmware vulnerabili o delle versioni corrette.
Origine del problema
Nel manifest esaminato durante la ricerca,
MiracastService risulta accessibile dall’esterno
perché dichiara android:exported="true", senza
richiedere un permesso per accedere al servizio. L’applicazione
dichiara inoltre
android:sharedUserId="android.uid.system".
Il metodo onStartCommand() del servizio legge il
parametro booleano screen_share dell’intent senza
controllare se il chiamante sia autorizzato a gestire Miracast.
Le operazioni vengono poi eseguite con i privilegi del servizio.
È il meccanismo del confused deputy: un componente privilegiato
agisce per conto di un chiamante di cui non ha verificato
l’autorizzazione.
Nell’implementazione analizzata, il ramo di esecuzione associato
a screen_share=false può chiamare
WifiP2pManager.createGroup(). Questo avviene solo
se, nello stato del servizio, la condivisione dello schermo è
disabilitata, il Wi-Fi P2P è attivo e non esiste già un gruppo.
L’analisi del codice mostra anche una scrittura eseguita con
Settings.Global.putInt(..., "miracast_enable", 1)
in onCreate(). Questa operazione è stata
individuata nel codice; l’estratto di log riportato sotto non ne
dimostra l’esecuzione.
Cosa dimostrano i risultati
MediaTek segnala un rischio di denial of service locale. Sulla
TV analizzata, la sessione ADB documenta che il servizio accetta
screen_share=false e crea un gruppo Wi-Fi Direct.
La shell ADB usa l’identità della shell di Android, diversa dall’UID di una normale applicazione. I comandi e i log mostrano il comportamento ottenuto via ADB. Non bastano a dimostrare che lo stesso risultato sia ottenibile da un’applicazione priva di permessi. In questa ricerca non è incluso un test separato condotto tramite app.
L’estratto non dimostra l’esecuzione di codice arbitrario, l’ottenimento di una shell root, il collegamento di un dispositivo nelle vicinanze o la rimozione del gruppo. Il chiamante non acquisisce l’UID di sistema: induce il servizio a eseguire un’operazione per suo conto.
Riprodurre il test
Prerequisiti
- Il firmware usato nel test, oppure una build equivalente che esponga lo stesso componente vulnerabile.
- ADB installato sul computer e una connessione di debug autorizzata verso una TV propria o per cui si dispone dell’autorizzazione a eseguire il test.
- Wi-Fi e Wi-Fi Direct disponibili sulla TV.
- Due terminali sul computer. I comandi seguenti richiedono Bash o WSL con accesso ad ADB.
Monitorare i log del servizio
adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'Preparare lo stato del ricevitore
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true
sleep 3
adb shell am force-stop com.mediatek.androidbox
sleep 2La sequenza seguente è quella usata per preparare il dispositivo nel test originale. L’arresto forzato del pacchetto non garantisce che Android abbia eliminato un eventuale gruppo Wi-Fi Direct già attivo.
Richiedere la creazione del gruppo
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false
Cerca Enter createGroup seguito da
createGroup success. Se compare solo
Received screen_share tag, il servizio ha elaborato
l’intent, ma questo non dimostra che il gruppo sia stato creato.
Richiedere il ripristino e verificare la TV
adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share trueControlla dalle impostazioni della TV che casting e Wi-Fi Direct siano tornati allo stato desiderato. La ricezione dell’intent, da sola, non conferma che il ripristino sia riuscito.
I log originali del test
Questo estratto di logcat è stato acquisito sulla TV durante il test del 10 marzo 2026. Il log proviene dalla ricerca originale: non è stato eseguito un nuovo test per questa pubblicazione.
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
Le prime tre righe documentano la ricezione del parametro,
l’esecuzione del ramo che crea il gruppo e il callback che ne
conferma la creazione. L’ultima riga mostra soltanto la
ricezione del valore true; manca un callback che
confermi la rimozione del gruppo.
Interventi correttivi
Per correggere il problema occorre un aggiornamento firmware del
produttore della TV che includa le patch indicate da MediaTek
come ALPS11060069 / DTV04881615.
Durante questa ricerca non è stata verificata una versione del
firmware PEAQ contenente la correzione.
Per gli sviluppatori del componente: se non è necessario
ricevere richieste esterne, disabilitare l’esportazione del
servizio impostando android:exported="false". Se
altre applicazioni attendibili devono accedervi, richiedere un
permesso di livello signature e verificare l’autorizzazione del
chiamante prima di modificare lo stato del ricevitore.
Cronologia della segnalazione
| 10 marzo 2026 | Test originale sul dispositivo e acquisizione dei log. |
|---|---|
| 7 settembre 2026 | Pubblicazione del bollettino di sicurezza MediaTek con CVE-2026-20516. |
| 11 settembre 2026 | Pubblicazione dell’analisi e della PoC, dopo la disclosure coordinata e l’approvazione di MediaTek. |