Il 14 settembre 2026 IlSoftware.it ha riportato la dimostrazione di Lukas Maar: un’app Android priva di permessi speciali avrebbe ottenuto una shell con UID 0 su telefoni stock, con bootloader bloccato e Verified Boot attivo. La ricerca OEMpocalypse Now punta al codice aggiunto dai produttori e i dettagli completi delle vulnerabilità restano rinviati alle prossime parti dell’analisi.
In breve
- Una app senza permessi può arrivare, secondo la ricostruzione, a una shell con UID 0.
- I test citati coprono sei telefoni Samsung, Xiaomi, Oppo e OnePlus.
- I dispositivi usano kernel compresi tra Linux 5.15 e 6.12.
- Il meccanismo indicato sfrutta un difetto page use-after-free nella memoria.
- Verified Boot protegge l’avvio, non elimina una possibile escalation di privilegi durante l’esecuzione.
Sommario
Che cosa mostra OEMpocalypse sui telefoni Android
La dimostrazione descritta parte da un’app collocata nella sandbox standard di Android e arriva all’accesso root senza modificare il firmware installato. Secondo IlSoftware.it, la catena agirebbe su dispositivi con configurazione originale, bootloader bloccato e verifica dell’avvio abilitata.
Android separa le app attraverso gli UID Linux e usa SELinux per limitare le azioni dei processi non privilegiati. Android 8 ha esteso inoltre i filtri seccomp-bpf a tutte le applicazioni, riducendo le chiamate di sistema disponibili. Queste protezioni rendono difficile raggiungere direttamente il kernel Linux da una normale app.
OEMpocalypse Now non sostiene però che tali barriere siano inutili. La ricerca mostra un percorso diverso: una protezione runtime può essere aggirata quando un componente privilegiato aggiunto dal produttore espone un comportamento vulnerabile. L’obiettivo dichiarato è ottenere una escalation di privilegi sfruttando il software che accompagna un marchio su più modelli.
I modelli coinvolti e il percorso verso i privilegi root
I test riportati coinvolgono telefoni con piattaforme hardware differenti, elemento centrale per la portata della ricerca. La selezione attraversa generazioni e famiglie software distinte, senza concentrarsi su un solo chipset.
| Produttore | Modelli citati | Kernel Linux |
|---|---|---|
| Samsung | Galaxy S23, Galaxy S26, Galaxy S26 Ultra | 5.15–6.12 |
| Xiaomi | Xiaomi 17 | 5.15–6.12 |
| Oppo | Oppo Find X9 Ultra | 5.15–6.12 |
| OnePlus | OnePlus Ace 6 Ultra | 5.15–6.12 |
Il percorso illustrato non porta l’app ad attaccare subito il kernel. Prima sfrutterebbe un servizio o un processo già autorizzato a comunicare con driver proprietari normalmente irraggiungibili dalla sandbox. Quel processo agirebbe come intermediario privilegiato.
La fase decisiva sarebbe una page use-after-free. Un driver libera una pagina di memoria, ma conserva un riferimento oppure una mappatura ancora utilizzabile. Il kernel può riassegnare quella pagina ad altri dati; chi mantiene il vecchio accesso potrebbe leggere o modificare contenuti ormai destinati a strutture diverse. Se vengono coinvolti dati sensibili del kernel, la catena può arrivare ai privilegi root.
Perché il codice dei produttori è al centro della ricerca
OEMpocalypse Now concentra l’attenzione su driver, servizi e componenti proprietari inseriti dagli OEM sopra Android. Samsung, Xiaomi, Oppo e OnePlus personalizzano il sistema con software che può restare presente anche quando cambiano processore, memoria o configurazione del telefono.
Questo approccio differisce dalla ricerca di una falla comune nel kernel Linux o in un driver legato a una singola piattaforma hardware. Un difetto nel codice OEM può seguire la famiglia software del produttore tra dispositivi con SoC Qualcomm, MediaTek, Snapdragon o Exynos. La copertura potenziale dipende quindi dalla diffusione di quel componente, non dal chip installato.
Tra gli esempi di strati software collegati ai marchi figurano One UI di Samsung, HyperOS di Xiaomi e ColorOS della famiglia Oppo. Anche Realme rientra tra i dispositivi potenzialmente accomunati dalla famiglia software Oppo. Non viene indicata una singola vulnerabilità universale per Android: ciascuna catena sarebbe dedicata a uno specifico produttore.
SELinux continua a limitare l’accesso diretto ai componenti sensibili. Tuttavia, se un servizio privilegiato espone un’interfaccia raggiungibile dall’app e il driver gestisce male la memoria, il controllo imposto dalla sandbox può non bastare a fermare l’escalation.
Cosa cambia per utenti e produttori, in attesa dei dettagli
Verified Boot verifica l’integrità del software durante l’avvio e il bootloader bloccato impedisce modifiche non autorizzate alla catena di boot. La dimostrazione attribuita a Maar segnala che queste misure non bloccano necessariamente un attacco avviato quando Android è già acceso, se una vulnerabilità consente l’accesso root a runtime.
Per i produttori il nodo riguarda la gestione corretta di riferimenti, mapping e pagine condivise nei driver. Una pagina liberata deve perdere ogni accesso prima che il kernel possa riutilizzarla. Servizi privilegiati, daemon e driver personalizzati entrano così nel perimetro di sicurezza del dispositivo, non restano elementi marginali.
Le prossime parti dell’analisi dovranno identificare le vulnerabilità specifiche e le catene previste per Samsung, Xiaomi e la famiglia Oppo, OnePlus e Realme. Da quelle pubblicazioni dipenderanno conferme tecniche, correzioni degli OEM e l’eventuale disponibilità di patch per i modelli citati.
