CVE-2026-20516: MiracastService confused deputy su Android TV

Ricerca e divulgazione a cura di Davide Di Matteo (@Dingo97).

Questo è il mio primo CVE accreditato. Ho trovato un servizio Miracast esportato in modo improprio e con privilegi di sistema mentre analizzavo una PEAQ Android TV. Un chiamante può fornire un intent extra che induce il servizio a modificare lo stato del Wi-Fi Direct utilizzando i propri privilegi.

MediaTek ha pubblicato il problema nel suo bollettino di sicurezza di settembre 2026 e accredita Davide Di Matteo nei suoi ringraziamenti di sicurezza. Questo write-up e la riproduzione ADB originale sono pubblicati in seguito alla divulgazione coordinata e con il permesso del fornitore.

Leggi sul mio sito · Repository GitHub

Riepilogo della vulnerabilità

L'impatto, gli identificatori della patch e i prerequisiti di attacco locale sono documentati nel record CVE. Il punteggio numerico e il vettore sopra riportati sono quelli pubblicati da Tenable. Sostituiscono la valutazione preliminare di 5.1 presente nel mio report originale. CWE-284 (improper access control) e CWE-441 (confused deputy) descrivono l'analisi originale; MediaTek classifica il problema come CWE-926.

Ambiente testato

Questi sono i dettagli del dispositivo utilizzato per la ricerca originale, non un elenco di tutte le versioni firmware vulnerabili o corrette.

Causa principale

L'analisi del manifest registrata nel report originale mostra che MiracastService è esportato con android:exported="true", senza un permesso che protegga l'accesso al servizio. L'applicazione dichiara android:sharedUserId="android.uid.system".

Il metodo onStartCommand() del servizio legge l'intent extra booleano screen_share senza verificare se il chiamante è autorizzato a controllare Miracast. Il servizio esegue quindi operazioni nel proprio contesto privilegiato. Questo è il confused deputy: il chiamante fornisce la richiesta, mentre il servizio di sistema fornisce l'autorità.

Nell'implementazione analizzata, il percorso screen_share=false può chiamare WifiP2pManager.createGroup(). La chiamata è condizionale: la condivisione dello schermo deve essere disabilitata nello stato del servizio, il Wi-Fi P2P deve essere abilitato e non deve esistere già un gruppo. Il nome del booleano non deve essere interpretato come un'affermazione diretta sul fatto che un gruppo verrà creato o rimosso.

Il report registra anche una scrittura su Settings.Global.putInt(..., "miracast_enable", 1) in onCreate(). L'attivazione del ciclo di vita del servizio può quindi causare una scrittura su impostazioni protette tramite il servizio. Questa è un'osservazione derivante dall'analisi dell'implementazione; l'estratto di log riportato di seguito non dimostra autonomamente tale scrittura.

I controlli dei permessi rilevanti dipendono dal framework Android e dalla build OEM. Il problema chiave è l'autorizzazione mancante al confine del servizio esportato, piuttosto che l'affermazione che ogni versione di Android applichi un insieme di permessi identico per il Wi-Fi Direct.

Impatto e limiti delle prove

MediaTek descrive un rischio di denial-of-service locale. Sulla TV testata, la sessione ADB registrata mostra il servizio che accetta screen_share=false e crea con successo un gruppo Wi-Fi Direct. Modifiche impreviste a questo stato possono interferire con l'uso legittimo di Miracast e possono esporre uno stato del ricevitore che l'utente non ha richiesto.

Il componente esportato e il controllo di accesso mancante supportano un percorso di attacco da app locale nell'analisi originale. La shell ADB viene eseguita con l'identità shell di Android, non con un UID di applicazione ordinario. Di conseguenza, questi comandi e log dimostrano il comportamento del servizio da ADB; non provano, di per sé, l'esecuzione da un'applicazione senza permessi. Questo repository non include una riproduzione basata su applicazione testata separatamente.

L'estratto non stabilisce esecuzione di codice arbitrario, una shell root, una connessione completata da un dispositivo vicino o una rimozione riuscita del gruppo. Il chiamante non acquisisce l'UID di sistema del servizio; induce il servizio ad agire per suo conto.

Proof of concept

Prerequisiti

• Il firmware vulnerabile testato, o una build equivalente che esponga lo stesso componente.
• ADB installato sull'host e una connessione di debug autorizzata a una TV di tua proprietà o che sei autorizzato a testare.
• Wi-Fi e Wi-Fi Direct disponibili sulla TV.
• Due terminali. I comandi host riportati di seguito utilizzano una shell POSIX, ad esempio Bash o WSL con accesso ad ADB.

Quella che segue è la riproduzione manuale dal report originale. Modifica lo stato di Miracast e forza l'arresto del pacchetto del ricevitore. Registra lo stato di casting corrente prima di eseguirla.

1. Monitorare il servizio

Nel primo terminale:

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

2. Preparare lo stato del ricevitore

Nel secondo terminale:

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

Questa è la sequenza di reset utilizzata nella riproduzione originale. Un force-stop del pacchetto non garantisce che il sottosistema Wi-Fi di Android abbia rimosso un gruppo esistente. Se un gruppo persiste, reimposta il ricevitore tramite i controlli della TV e verifica il suo stato prima di riprovare.

3. 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, l'intent è stato elaborato, ma la creazione del gruppo non è stata dimostrata: verifica i prerequisiti descritti sopra.

4. Richiedere la pulizia e verificare la TV

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

Questo invia il valore di pulizia utilizzato nel report originale. Verifica che il casting e il Wi-Fi Direct siano tornati allo stato desiderato utilizzando i controlli della TV. La sola ricezione dell'intent non è prova che la pulizia sia riuscita; ripristina manualmente il ricevitore se necessario.

Prove acquisite

Il seguente estratto di logcat è stato acquisito sulla TV testata il 10 marzo 2026. È una prova della ricerca originale, non un nuovo test eseguito 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 mostrano la ricezione del parametro, l'ingresso nel percorso di creazione del gruppo e un callback riuscito. L'ultima riga mostra la ricezione di true; non include un callback di rimozione riuscita. Il PID 30288 è visibile, ma l'UID del processo e l'identità del chiamante non sono registrati in questo estratto.

Ambito interessato

La mia riproduzione è limitata alla configurazione PEAQ AI PONT sopra indicata. Il bollettino di MediaTek elenca chipset interessati oltre a quel dispositivo; consulta la voce CVE-2026-20516 del fornitore per l'ambito autorevole. L'inclusione di un chipset non identifica se una particolare TV retail ha ricevuto la correzione firmware del suo OEM.

La denominazione del pacchetto e dell'APK suggeriva un componente condiviso MediaTek/Changhong durante la ricerca originale. Questa sola osservazione non stabilisce la presenza di questo servizio esportato su ogni TV basata su MediaTek.

Remediation

I proprietari dei dispositivi dovrebbero ottenere dal produttore della TV un firmware contenente la correzione pertinente. MediaTek identifica le correzioni come ALPS11060069 / DTV04881615; nessuna versione firmware PEAQ corretta è stata verificata nell'ambito di questo write-up.

Per i manutentori del componente, rimuovere l'esposizione esterna con android:exported="false" se i chiamanti esterni non sono necessari. Se è richiesto un accesso affidabile tra applicazioni, proteggere il servizio con un permesso appropriato a livello di firma e applicare l'autorizzazione prima di modificare lo stato del ricevitore. Rivedere tutti i punti di ingresso e gli effetti collaterali del ciclo di vita, incluse le scritture su impostazioni protette.

Queste sono raccomandazioni di hardening derivanti dall'analisi, non una descrizione della patch del fornitore non pubblicata. Convalidare il risultato utilizzando un UID di applicazione ordinario oltre a client di casting legittimi.

Cronologia della divulgazione e crediti

Scoperto e segnalato da Davide Di Matteo. Grazie a MediaTek per aver coordinato la divulgazione e aver riconosciuto la ricerca nei suoi crediti di settembre 2026.

Riferimenti

• MediaTek — Bollettino di sicurezza di settembre 2026
• MediaTek — Ringraziamenti di sicurezza
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516