Android, da una normale app a root: OEMpocalypse colpisce Samsung, Xiaomi e OnePlus

Un’app Android installata senza richiedere alcun permesso particolare, uno smartphone con firmware originale, bootloader bloccato e Verified Boot ancora attivo. Poi, pochi istanti dopo, una shell con UID 0 cioè una console con i privilegi dell’utente root, il livello di accesso più elevato nei sistemi Linux su cui Android si basa. È lo scenario mostrato dal ricercatore Lukas Maar con il progetto OEMpocalypse Now, una ricerca che mette sotto osservazione una parte spesso meno discussa della sicurezza Android: il codice aggiunto dai produttori sopra la piattaforma sviluppata da Google.

Come OEMpocalypse Now supera le difese che proteggono le app Android

Android ha progressivamente costruito una barriera robusta attorno alle applicazioni. La sandbox basata sugli UID Linux esiste dalle prime versioni; SELinux è diventato un elemento centrale della separazione dei privilegi da Android 5, mentre Android 8 ha esteso a tutte le app l’uso dei filtri seccomp-bpf, un meccanismo del kernel Linux che limita l’insieme delle system call che un processo può invocare. In pratica, anche se un’app prova a richiamare direttamente una funzione del kernel potenzialmente pericolosa, il filtro può bloccarla prima ancora che la richiesta raggiunga il codice interessato.

Con Android 9, la separazione SELinux delle applicazioni non privilegiate è diventata ancora più granulare. Il risultato è che una normale app di terze parti parte da una posizione fortemente limitata e, in condizioni normali, non dovrebbe riuscire ad avvicinarsi alle aree più sensibili del kernel.

OEMpocalypse Now mostra però un’altra faccia del problema. Maar sostiene di aver costruito tre famiglie di catene di exploit capaci di passare da una normale applicazione nel dominio untrusted_app ai privilegi di root su smartphone Samsung, Xiaomi e sui dispositivi della famiglia Oppo, comprendente anche OnePlus e Realme. Nei test pubblicati compaiono Galaxy S23, Galaxy S26, Galaxy S26 Ultra, Xiaomi 17, Oppo Find X9 Ultra e OnePlus Ace 6 Ultra, con kernel compresi tra Linux 5.15 e 6.12.

La ricerca propone un metodo generale: invece di cercare una singola vulnerabilità Linux utilizzabile ovunque, punta deliberatamente sul software proprietario aggiunto dagli OEM. È una scelta apparentemente meno universale, ma può rendere l’exploit molto più stabile all’interno dell’intera famiglia di dispositivi di uno stesso produttore.

Le tre strade verso root: Linux, chipset oppure codice OEM

La ricerca pubblicata da Calif mette in evidenza che una parte significativa della superficie d’attacco Android può nascondersi proprio nel codice aggiunto dai produttori: driver, servizi e componenti privilegiati che, se vulnerabili, possono permettere a una normale app di superare le protezioni della sandbox e arrivare fino ai privilegi di root.

Un primo approccio illustrato da Maar consiste nel colpire il kernel Linux o l’Android Common Kernel: se la vulnerabilità risiede all’interno di codice comune, lo stesso difetto può comparire su telefoni di produttori differenti. Una vulnerabilità presente su molti dispositivi, tuttavia, non implica automaticamente un exploit altrettanto portabile, questo perché le differenze tra i vari device sono determinanti.

Kernel 5.15 e 6.12 possono organizzare la memoria in maniera diversa; i produttori aggiungono patch proprie; cambiano opzioni di compilazione, quantità di RAM, numero di CPU e configurazione degli allocator. Samsung, per esempio, applica ulteriori meccanismi di protezione del kernel. Una tecnica teoricamente universale rischia quindi di trasformarsi in una collezione di “casi speciali”.

La seconda strada passa dai driver dei chipset. GPU, DSP e NPU sono bersagli molto interessanti perché devono gestire direttamente pagine fisiche, mapping DMA e tabelle di paginazione del dispositivo. Errori nella gestione del ciclo di vita della memoria possono fornire primitive potenti.

Vulnerabilità nei driver Mali, Adreno e Qualcomm adsprpc sono comparse più volte sia nei laboratori sia in attacchi reali. Ma rimane un limite: la copertura segue il chipset, non il marchio dello smartphone. Samsung può utilizzare Snapdragon in un modello e Exynos in un altro; altri produttori alternano Qualcomm e MediaTek. Lo stesso exploit non accompagna necessariamente tutta la gamma.

Maar ha scelto una terza via: cercare gli errori nel software che Samsung, Xiaomi, Oppo e gli altri OEM aggiungono ad Android.

La debolezza che segue il produttore invece del chip

Un componente sviluppato da Samsung può ritrovarsi su telefoni con Snapdragon ed Exynos. Allo stesso modo un servizio Oppo può restare sostanzialmente identico su dispositivi costruiti attorno a SoC Qualcomm o MediaTek.

OEMpocalypse Now cerca componenti legati alla personalizzazione software del produttore, per esempio One UI, HyperOS o ColorOS, anziché all’hardware sottostante. Se il driver vulnerabile compare su buona parte della gamma, la stessa vulnerabilità può seguire il produttore attraverso generazioni di smartphone molto diverse.

Il ricercatore imposta tre obiettivi: affidabilità vicina al 100%, pochi adattamenti tra una versione e l’altra e copertura del maggior numero possibile di dispositivi. Non pretende di ottenere una vulnerabilità universale per Android; restringe deliberatamente il bersaglio a ciascun OEM per ottenere maggiore stabilità.

Come OEMpocalypse Now arriva ai privilegi di root

Il primo ostacolo è SELinux: molte app Android non possono accedere direttamente ai driver proprietari fondamentali.

OEMpocalypse Now aggira il problema sfruttando, quando serve, un servizio o un processo privilegiato che invece può comunicare con quel driver. In pratica, l’app non attacca subito il kernel: cerca prima un intermediario autorizzato.

La fase successiva sfrutta una classe di bug chiamata page use-after-free. Un driver libera una pagina di memoria ma lascia ancora attivo un riferimento o un mapping verso di essa. Il kernel può quindi riutilizzare quella stessa pagina per dati differenti, mentre l’attaccante conserva ancora la possibilità di leggerla o modificarla.

È qui che l’attacco diventa particolarmente potente. Se la pagina finisce per contenere strutture rilevanti del kernel, chi controlla il vecchio mapping può alterare dati privilegiati e arrivare fino a root.

I test su Samsung, Xiaomi, Oppo e OnePlus

Calif ha mostrato le proprie catene di exploit su diversi smartphone reali, tra cui Galaxy S23, Galaxy S26, Galaxy S26 Ultra, Xiaomi 17, Oppo Find X9 Ultra e OnePlus Ace 6 Ultra. I dispositivi utilizzano chipset differenti e kernel compresi tra Linux 5.15 e 6.12, dettaglio che rafforza uno dei punti centrali della ricerca: colpendo componenti specifici del produttore, l’exploit può restare valido anche quando cambia il SoC.

Le dimostrazioni partono da una normale applicazione Android senza permessi particolari e arrivano a una shell con UID 0. I telefoni risultano inoltre in configurazione stock, con Verified Boot attivo e bootloader bloccato: non si tratta quindi di dispositivi modificati o predisposti per il modding.

Va detto però che la ricerca pubblicata finora descrive soprattutto l’approccio generale. I dettagli completi delle singole vulnerabilità e delle catene dedicate a Samsung, Xiaomi e alla famiglia Oppo/OnePlus/Realme sono demandati alle parti successive dell’analisi.

Perché il codice aggiunto dagli OEM è così importante

Il punto centrale di OEMpocalypse Now è proprio questo: il kernel Linux e i componenti Android più comuni ricevono da tempo un’enorme attenzione da parte dei ricercatori, mentre driver e servizi proprietari introdotti dai produttori possono contenere difetti meno studiati.

SELinux riduce fortemente la superficie di attacco, ma non può correggere un errore all’interno di un driver. Se un processo privilegiato può raggiungere quel componente e un’app riesce a controllare indirettamente il processo, la vulnerabilità torna sfruttabile.

Per gli OEM la difesa principale resta quindi una gestione rigorosa della memoria nei driver: riferimenti, mapping e pagine condivise devono essere eliminati nell’ordine corretto prima che il kernel possa riutilizzare la memoria. Verified Boot e bootloader bloccato proteggono invece l’integrità del software installato e della fase di avvio, ma non impediscono a una vulnerabilità a runtime di ottenere privilegi mentre Android è già in esecuzione.

Il codice aggiunto ad Android dagli sviluppatori terzi non è un semplice strato accessorio sopra una base sicura: servizi, daemon e driver personalizzati entrano direttamente nel modello di sicurezza del dispositivo. Se uno di questi componenti gestisce male una pagina fisica e un secondo errore permette a un’app di raggiungerlo, le difese costruite attorno alla sandbox possono trasformarsi da barriera finale a semplice ostacolo intermedio.

Note finali

Lo studio di Calif merita quindi di essere seguito con attenzione: la prima parte chiarisce il metodo e mostra la portata delle catene di exploit, ma sono le analisi successive a dover spiegare nel dettaglio quali componenti OEM risultano vulnerabili e come funzionano i singoli passaggi.

È proprio lì che emergerà il valore tecnico maggiore della ricerca, soprattutto per capire quanto siano diffuse queste debolezze e quali correzioni dovranno adottare Samsung, Xiaomi, Oppo, OnePlus e Realme.