GhostMap su Android: quando il parser di un APK può bloccare l’intero telefono

Su Android siamo abituati a ragionare di permessi: un’app può accedere ai contatti? Può leggere i file? Può usare il microfono? GhostMap mostra un problema diverso. Secondo la ricerca pubblicata da Bitdefender Labs il 5 novembre 2026, un pacchetto APK costruito in modo particolare può compromettere la disponibilità del dispositivo senza eseguire codice e senza richiedere alcun permesso. Non è una dimostrazione di furto dei dati: è un caso di denial of service persistente, e proprio per questo merita attenzione.

Il confine di sicurezza attraversato prima di aprire l’app

Un APK è un archivio ZIP che contiene codice e risorse. Android deve leggerne diversi elementi già durante l’installazione e successivamente, quando il sistema carica icone e altre risorse. La superficie di attacco non comincia quindi quando l’utente tocca l’icona: comincia quando un componente privilegiato interpreta dati provenienti da un file esterno.

La ricerca tecnica di Bitdefender descrive un disaccordo tra due librerie Android. libziparchive applica un controllo sulle dimensioni dichiarate di una voce ZIP solo quando il metodo di compressione è quello non compresso, mentre libandroidfw tratta come non compresse anche alcune voci che non sono marcate come deflate. Un valore del metodo diverso da quelli previsti può attraversare il primo controllo e arrivare alla seconda libreria con una lunghezza dichiarata non coerente con i byte effettivamente disponibili.

Quando il sistema mappa quella risorsa in memoria e tenta di leggere oltre la parte realmente presente nel file, il processo può ricevere un segnale SIGBUS. Il punto non è una misteriosa capacità dell’APK di eseguire istruzioni: è un errore di interpretazione e validazione del formato. Due componenti fidati attribuiscono significati diversi agli stessi byte.

Dal crash di un processo al ciclo che rende inutilizzabile il dispositivo

Un processo applicativo che va in crash è già un problema, ma spesso è circoscritto. La situazione cambia quando la lettura della risorsa malformata avviene in un servizio centrale come system_server. Il servizio cade, Android tenta di riavviarlo, il sistema torna a leggere la stessa risorsa e il ciclo ricomincia. Nei test di Bitdefender il blocco è persistito anche dopo il riavvio e in modalità provvisoria.

I ricercatori riferiscono di aver riprodotto il comportamento su un Pixel 10 con Android 17 e patch del 5 agosto 2026, e di aver verificato il difetto su versioni Android a partire dalla 10. Questo non autorizza a dichiarare che ogni modello e ogni configurazione siano stati testati o che milioni di telefoni siano già compromessi.

L’indagine è partita da un campione di malware bancario raccolto in circolazione che mandava in crash gli emulatori di analisi durante l’installazione. La trasformazione del difetto in un crash loop persistente è invece il risultato del lavoro di laboratorio di Bitdefender. Gli autori precisano di non aver osservato l’impiego di quel meccanismo contro vittime reali. Confondere il campione iniziale con una campagna GhostMap già attiva significherebbe trasformare un dato tecnico in allarmismo.

Perché il modello dei permessi non basta

Il sistema dei permessi serve a limitare le operazioni consentite al codice di un’app. Non può sostituire la validazione dei dati letti dai servizi di sistema. Un file malevolo può essere pericoloso anche quando non contiene codice eseguibile: basta che venga interpretato automaticamente da un componente con responsabilità più ampie.

È un principio che va oltre Android. Parser di documenti, immagini, archivi e metadati operano spesso in processi che consideriamo affidabili. Se la stessa struttura viene validata da una libreria e consumata da un’altra, le differenze semantiche diventano una superficie di attacco. La difesa non consiste soltanto nel controllare chi può eseguire codice, ma nel rendere coerenti le regole con cui i dati vengono accettati e utilizzati.

La disponibilità di un sistema dipende anche da ciò che i suoi componenti leggono automaticamente, non soltanto dai permessi concessi alle applicazioni.

Recovery, backup e costo reale di un denial of service

Per un telefono personale, un ripristino di fabbrica è una seccatura. Per un dispositivo di lavoro può significare interruzione dell’accesso ad autenticazione a due fattori, messaggistica, strumenti aziendali e documenti locali. È un rischio operativo, anche senza esfiltrazione dei dati. Il danno dipende da quanto il dispositivo sia sostituibile e da quanto siano recuperabili le informazioni necessarie a tornare produttivi.

Bitdefender indica il reset come possibile strada di recupero, con perdita dei dati locali non salvati. Descrive anche una possibilità limitata tramite ADB, soltanto se il debug USB era già abilitato e si riesce a intervenire nella breve finestra utile. Non è una procedura universale né un motivo per abilitare indiscriminatamente il debug USB sui telefoni aziendali.

La risposta pratica è meno spettacolare dell’exploit: limitare l’installazione di APK da origini non attendibili, mantenere aggiornati i dispositivi, verificare che backup e ripristino siano effettivamente utilizzabili, documentare il recupero delle credenziali e dei fattori di autenticazione. In un parco dispositivi gestito, questi controlli devono entrare nei piani di continuità, non rimanere una raccomandazione generica rivolta agli utenti.

La questione della patch e della classificazione

Bitdefender dichiara di aver segnalato il problema a Google il 20 e il 25 agosto 2026. Secondo il laboratorio, dopo la seconda segnalazione Google ha considerato il caso fuori dall’ambito di una correzione tramite aggiornamento di sicurezza, inoltrandolo a un team per una possibile versione futura. Questo è il resoconto della disclosure pubblicato dal ricercatore, non la prova di un calendario di rilascio: alla data dell’8 novembre 2026 non emerge dalla fonte primaria una patch con data confermata.

Il punto interessante è la differenza tra una vulnerabilità che sottrae dati e una che rende il dispositivo indisponibile fino a un possibile reset. Anche la seconda può avere un impatto severo, soprattutto quando il recupero richiede la cancellazione dello stato locale. La valutazione del rischio dovrebbe guardare al tempo di ripristino, alla dipendenza dal dispositivo e alla perdita potenziale, non soltanto alla presenza di esecuzione remota di codice.

La lezione per chi sviluppa sistemi

GhostMap è un caso utile per ragionare sui confini di fiducia. Un input passa da un validatore a un consumatore: se il primo ammette una condizione che il secondo interpreta diversamente, il controllo può diventare illusorio. In fase di progettazione questo richiede formati canonici, rifiuto dei valori non supportati, test differenziali tra parser e attenzione ai processi che caricano risorse senza intervento dell’utente.

Non serve attribuire al caso capacità che non sono state dimostrate. La scoperta è già significativa così: un pacchetto privo di codice può rendere indisponibile un sistema perché un servizio centrale si fida di metadati che un altro componente non ha validato nello stesso modo. La sicurezza, in questo scenario, è soprattutto coerenza tra componenti e capacità di recupero quando quella coerenza viene meno.