Stagefright: l'exploit che ha cambiato Android

Uno dei punti di forza di Android è stata principalmente la sua natura open source, che consente alle parti interessate di creare un fork, modificare e ridistribuire il sistema operativo in un modo che si adatti alle loro esigenze particolari. Ma proprio questo vantaggio di essere open source agisce come un’arma a doppio taglio quando si tratta di problemi di malware e sicurezza. È più facile trovare e correggere i difetti quando ci sono molti contributori capaci su un progetto il cui codice sorgente è disponibile liberamente. Tuttavia, risolvere il problema a livello della fonte spesso non si traduce nel fatto che il problema venga risolto nelle mani del consumatore finale. Pertanto, Android non è la scelta migliore quando si tratta di scegliere un sistema operativo per esigenze aziendali sensibili ai dati.

Al Google I/O 2014, Google ha dato il primo impulso verso un ecosistema più sicuro e adatto alle imprese con il lancio del

Programma Android For Work. Android For Work ha adottato un approccio a doppio profilo per le esigenze aziendali, in base al quale gli amministratori IT potevano creare un file profili utente distinti per i dipendenti: uno focalizzato sul lavoro, lasciando gli altri profili personali per i dipendenti utilizzo. Attraverso l'uso della crittografia basata su hardware e di policy gestite dall'amministratore, i dati personali e di lavoro sono rimasti distinti e sicuri. Successivamente, Android For Work ha ricevuto maggiore attenzione nei mesi successivi, con particolare attenzione alla sicurezza del dispositivo contro i malware. Anche Google ha pianificato di farlo abilitare la crittografia completa del dispositivo per tutti i dispositivi che dovevano essere rilasciati con Android Lollipop fuori dagli schemi, ma questo è stato scartato a causa di problemi di prestazioni con la mossa resa opzionale per l'implementazione da parte degli OEM.

La spinta per un Android sicuro non è interamente opera di Google, poiché Samsung ha svolto un ruolo piuttosto significativo in questo tramite il suo Contributi KNOX all'AOSP, che alla fine Android For Work rafforzato. Tuttavia, i recenti exploit di sicurezza e vulnerabilità in Android indicano un compito arduo quando si tratta di popolarità per l’adozione aziendale. Un esempio calzante è la recente vulnerabilità Stagefright.

Contenuti:

• Cos'è la paura del palcoscenico?
• Quanto è serio Stagefright?
• Cosa rende Stagefright diverso da altre "massicce vulnerabilità"?
• Il dilemma dell’aggiornamento
• Android, dopo la paura del palcoscenico
• Note di chiusura

Cos'è la paura del palcoscenico?

In termini semplici, Stagefright è un exploit che utilizza la libreria di codici per la riproduzione multimediale in Android chiamata libstagefright. Il motore libstagefright viene utilizzato per eseguire il codice che viene ricevuto sotto forma di video dannoso tramite MMS e per poter sferrare un attacco riuscito è sufficiente solo il numero di cellulare della vittima.

Abbiamo contattato il nostro esperto interno, lo sviluppatore riconosciuto senior XDA e l'amministratore dello sviluppatore pulsatore_g2 per fornire una spiegazione più dettagliata.

"Mentre scrivo questo, l'exploit [Stagefright] avrebbe dovuto essere spiegato a BlackHat [Collegamento], anche se non sono ancora disponibili diapositive o dettagli su white paper.

Sto quindi dando questa spiegazione più come un'idea approssimativa di cosa sta succedendo, piuttosto che come una spiegazione molto approfondita con piena accuratezza, ecc.

Ci sono una serie di bug diversi che compongono Stagefright e questi hanno il loro CVE [Vulnerabilità ed esposizioni comuni] numeri per il monitoraggio:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Sfortunatamente le patch disponibili non sono collegate direttamente a ciascun CVE (come dovrebbero essere), quindi sarà un po' complicato da spiegare.

1. [CVE-2015-1538]

Nel codice di gestione MPEG4, il codice di gestione dei metadati 3GPP (il materiale che descrive il formato e altre informazioni extra, quando un video è in formato 3GPP) è difettoso. Non ha rifiutato i metadati, laddove i dati erano eccessivamente grandi, ma ha solo controllato se erano troppo piccoli. Ciò significava che era possibile per un utente malintenzionato creare un file "modificato" o "corrotto", che avrebbe avuto una porzione di metadati più lunga del dovuto.

Una delle grandi sfide nella scrittura di codice per gestire dati "non attendibili" (ovvero provenienti da un utente o da qualsiasi altro tipo di luogo esterno al codice) è la gestione dei dati di lunghezza variabile. I video ne sono un perfetto esempio. Il software deve allocare la memoria in modo dinamico, a seconda di cosa sta succedendo.

In questo caso, viene creato un buffer come puntatore ad una parte di memoria, ma la lunghezza dell'array a cui punta era di un elemento troppo breve. I metadati venivano quindi letti in questo array ed era possibile che l'ultima voce in questo array non fosse "null" (o zero). È importante che l'ultimo elemento dell'array sia zero, poiché è così che il software comunica che l'array è terminato. Essendo in grado di rendere l'ultimo valore diverso da zero (poiché l'array era potenzialmente un elemento troppo piccolo), il codice dannoso potrebbe essere letto da un'altra parte di codice e leggere troppi dati. Invece di fermarsi alla fine di questo valore, potrebbe continuare a leggere altri dati che non dovrebbe leggere.

(Rif: OmniROM Gerrit)

2. [CVE-2015-1539]

La "dimensione" più breve possibile dei metadati dovrebbe essere di 6 byte, poiché si tratta di una stringa UTF-16. Il codice prende la dimensione del valore intero e ne sottrae 6. Se questo valore fosse inferiore a 6, la sottrazione "underflow" e si avvolgerebbe, e ci ritroveremmo con un numero molto grande. Immagina di poter contare solo da 0 a 65535, ad esempio. Se prendi il numero 4 e sottrai 6, non puoi scendere sotto lo zero. Quindi torni a 65535 e conti da lì. Questo è quello che sta succedendo qui!

Se viene ricevuta una lunghezza inferiore a 6, ciò potrebbe comportare una decodifica errata dei frame, poiché il file Il processo byteswap utilizza la variabile len16, il cui valore si ottiene da un calcolo che inizia con (taglia-6). Ciò potrebbe causare un'operazione di scambio molto più grande del previsto, che modificherebbe i valori nei dati del frame in modo imprevisto.

(Rif: OmniROM Gerrit)

3. [CVE-2015-3824]

Una cosa grossa! Questo è brutto. C'è l'esatto opposto di quest'ultimo problema: un overflow di numeri interi, in cui un numero intero può diventare "troppo grande". Se raggiungi 65535 (ad esempio) e non riesci a contare più in alto, rotolerai e andrai a 0 dopo!

Se stai allocando memoria in base a questo (che è ciò che Stagefright sta facendo!), ti ritroveresti con una memoria allocata troppo piccola nell'array. Quando i dati venivano inseriti in questo, potenzialmente sovrascrivevano dati non correlati con i dati controllati dal creatore del file dannoso.

(Rif: OmniROM Gerrit)

4. [CVE-2015-3826]

Un altro brutto! Molto simile all'ultimo: un altro overflow di numeri interi, in cui un array (utilizzato come buffer) verrebbe reso troppo piccolo. Ciò consentirebbe di sovrascrivere la memoria non correlata, il che è ancora una volta negativo. Qualcuno che può scrivere dati in memoria può corrompere altri dati non correlati e potenzialmente utilizzarli per far eseguire sul telefono un codice che controlla.

(Rif: OmniROM Gerrit)

5. [CVE-2015-3827]

Abbastanza simile a questi ultimi. Una variabile viene utilizzata quando si salta parte della memoria e questa potrebbe essere resa negativa durante una sottrazione (come sopra). Ciò si tradurrebbe in una lunghezza di "salto" molto ampia, in overflow di un buffer, dando accesso alla memoria a cui non si dovrebbe accedere.

(Rif: OmniROM Gerrit)

Ci sono anche alcune correzioni (potenzialmente) correlate che sembrano essere state introdotte anche in [Android] 5.1.

(Rif: OmniROM Gerrit)

Ciò aggiunge controlli per interrompere i problemi con una correzione di sicurezza precedente per aggiungere controlli dei limiti, che possono essere a loro volta superati. In C, i numeri che possono essere rappresentati come Signed Int vengono memorizzati come Signed Int. Altrimenti rimangono invariati durante le operazioni. In questi controlli, alcuni numeri interi avrebbero potuto essere resi con segno (anziché senza segno), il che ridurrebbe il loro valore massimo in seguito e consentirebbe il verificarsi di un overflow.

(Rif: OmniROM Gerrit)

Altri underflow di numeri interi (dove i numeri sono troppo bassi e quindi viene eseguita la sottrazione su quei numeri, consentendo loro di diventare negativi). Anche questo porta a un numero elevato, anziché piccolo, e ciò causa gli stessi problemi di cui sopra.

(Rif: OmniROM Gerrit)

E infine, un altro overflow di numeri interi. Come prima, sta per essere utilizzato altrove e potrebbe traboccare.

(Rif: OmniROM Gerrit)"

Quanto è serio Stagefright?

Secondo il post sul blog pubblicato dalla società di ricerca madre, Zimperium Research Labs, l'exploit Stagefright espone potenzialmente Il 95% dei dispositivi Android - circa 950 milioni - è affetto da questa vulnerabilità poiché colpisce i dispositivi con Android 2.2 e su. A peggiorare le cose, i dispositivi precedenti a Jelly Bean 4.3 corrono il “rischio peggiore” poiché non contengono adeguate attenuazioni contro questo exploit.

Per quanto riguarda il danno che Stagefright potrebbe causare, pulsar_g2 ha osservato:

[blockquoteauthor="pulser_g2"]"Di per sé, Stagefright darebbe accesso all'utente del sistema sul telefono. Tuttavia, dovresti bypassare ASLR (randomizzazione del layout dello spazio degli indirizzi) per abusarne effettivamente. Al momento non è noto se ciò sia stato raggiunto o meno. Questo exploit consente di eseguire "codice arbitrario" sul tuo dispositivo come utente del sistema o del supporto. Questi hanno accesso all'audio e alla fotocamera del dispositivo e l'utente del sistema è un ottimo posto da cui lanciare un exploit root. Ricordi tutti gli incredibili exploit di root che hai utilizzato per eseguire il root del tuo telefono?

Questi potrebbero essere potenzialmente utilizzati silenziosamente per ottenere il root sul tuo dispositivo! Chi ha root possiede il telefono. Dovrebbero bypassare SELinux, ma TowelRoot ci è riuscito, e anche PingPong ci è riuscito. Una volta ottenuto il root, tutto sul tuo telefono sarà aperto a loro. Messaggi, chiavi, ecc."[/blockquote]Parlando degli scenari peggiori, è necessario solo un MMS per consegnare il codice e attivare questo exploit. L'utente non è nemmeno necessario aprire il messaggio poiché molte app di messaggistica preelaborano gli MMS prima che l'utente interagisca con essi. Questo è diverso dagli attacchi di spear phishing in quanto l'utente potrebbe essere completamente ignaro di un attacco riuscito, compromettendo tutti i dati presenti e futuri nel telefono.

Cosa rende Stagefright diverso da altre “massicce vulnerabilità”?

"Tutte le vulnerabilità comportano qualche rischio per gli utenti. Questo è particolarmente rischioso, poiché se qualcuno trova un modo per attaccarlo da remoto (che è possibile, se fosse trovato un modo per aggirare l'ASLR), potrebbe essere attivato prima ancora che tu ti renda conto di essere sotto attacco"

Gli exploit più vecchi come Android Installer Hijacking, FakeID e gli exploit root come TowelRoot e PingPong richiedono l'interazione dell'utente ad un certo punto per essere eseguiti. Sebbene siano ancora degli “exploit” nel fatto che possono derivare molti danni se usati in modo dannoso, resta il fatto che Stagefright teoricamente ha bisogno solo del numero di cellulare della vittima per trasformare il suo telefono in un trojan e quindi negli ultimi tempi ha ricevuto così tanta attenzione giorni.

Tuttavia, Android non è del tutto in balia di questo exploit. L'ingegnere capo della sicurezza Android, Adrian Ludwig, ha affrontato alcune preoccupazioni in a Posta su Google+:

[blockquoteauthor="Adrian Ludwig"]"È opinione comune ed errata che qualsiasi bug del software possa essere trasformato in un exploit di sicurezza. In effetti, la maggior parte dei bug non sono sfruttabili e ci sono molte cose che Android ha fatto per migliorare queste probabilità...

Viene elencato un elenco di alcune delle tecnologie introdotte a partire da Ice Cream Sandwich (Android 4.0). Qui. Il più noto di questi è chiamato Address Space Layout Randomization (ASLR), che è stato completamente completato in Android 4.1 con supporto per PIE (Position Independent Executables) ed è ora presente su oltre l'85% di Android dispositivi. Questa tecnologia rende più difficile per un utente malintenzionato indovinare la posizione del codice, necessaria per creare un exploit di successo...

Non ci siamo fermati con ASLR, abbiamo anche aggiunto NX, FortifySource, Read-Only-Relocations, Stack Canaries e altro ancora."[/blockquote]

Tuttavia, non si può ancora negare che Stagefright sia una questione seria per il futuro di Android, e come tale viene presa sul serio dalle parti interessate. Stagefright ha anche evidenziato gli elefanti bianchi nella stanza: il problema della frammentazione e degli aggiornamenti che finalmente raggiungono il consumatore.

Il dilemma dell’aggiornamento

Parlando di aggiornamenti, è bello vedere che gli OEM si stanno assumendo la responsabilità della sicurezza degli utenti, come molti hanno promesso migliorare il processo di aggiornamento specificamente per incorporare correzioni di sicurezza e patch per exploit come Stagefright.

Tra i primi a rilasciare un comunicato ufficiale, Google lo ha promesso aggiornamenti mensili di sicurezza (oltre agli aggiornamenti pianificati del sistema operativo e della piattaforma) per la maggior parte dei suoi dispositivi Nexus, incluso il Nexus 4 di quasi 3 anni. Anche Samsung ha seguito l'esempio annunciando che lavorerà con operatori e partner per implementare un programma mensile di aggiornamento della sicurezza ma non è riuscito a specificare i dispositivi e i dettagli della sequenza temporale di questa implementazione. Questo è interessante in quanto menziona un approccio “fast track” agli aggiornamenti di sicurezza in collaborazione con gli operatori, così possiamo farlo aspettarsi aggiornamenti più frequenti (anche se basati sulla sicurezza, ma si spera che acceleri anche gli aggiornamenti del firmware) sull'operatore dispositivi.

Altri OEM che si uniscono al pacchetto includono LG che si unirà aggiornamenti mensili di sicurezza. Motorola ha anche annunciato il elenco dei dispositivi che verranno aggiornati con le correzioni di Stagefright e l'elenco include quasi tutti i dispositivi realizzati dall'azienda dal 2013. Lo ha detto anche Sony i suoi dispositivi riceveranno presto le patch pure.

Per una volta, anche gli operatori sono disponibili con aggiornamenti. Lo sprint ha ha rilasciato una dichiarazione che alcuni dispositivi hanno già ricevuto la patch Stagefright, con altri dispositivi programmati per l'aggiornamento. Anche AT&T ha seguito l'esempio rilasciando la patch ad alcuni dispositivi. Anche Verizon ha rilasciato delle patch, anche se si tratta di un lancio lento che dà priorità agli smartphone di fascia alta come Galaxy S6 Edge e Note 4. Anche il T-Mobile Note 4 ha ricevuto un aggiornamento della patch Stagefright.

Come utente finale, è possibile adottare alcune misure precauzionali per ridurre le possibilità di essere attaccati. Per cominciare, disabilita il recupero automatico dei messaggi MMS nelle app di messaggistica presenti sul tuo telefono. Ciò dovrebbe tenere sotto controllo i casi in cui non è stata richiesta alcuna interazione da parte dell'utente affinché l'exploit funzionasse. Successivamente, fai attenzione a evitare di scaricare contenuti multimediali da messaggi MMS da fonti sconosciute e non attendibili.

Come utente esperto di XDA, puoi anche farlo apporta modifiche al tuo oggetto di costruzione per disabilitare Stagefright. Questo non è un modo completo e sicuro per salvarti da Stagefright, ma puoi sfruttare le tue possibilità per ridurre la probabilità di un attacco riuscito se sei bloccato su una build Android precedente. Esistono anche soluzioni ROM personalizzate, la maggior parte delle quali sincronizza regolarmente le fonti con AOSP e quindi includerà le correzioni Stagefright. Se stai utilizzando una ROM basata su AOSP, ti consigliamo vivamente di eseguire l'aggiornamento a una versione più recente della ROM che incorpori le patch Stagefright. Puoi usare questa app per verificare se il tuo attuale conducente giornaliero è affetto da Stagefright.

Android, dopo la paura del palcoscenico

Stagefright non è stato altro che un campanello d'allarme nei confronti di Android e del suo problema di frammentazione e aggiornamenti. Evidenzia come non esista un meccanismo chiaro attraverso il quale tali soluzioni critiche possano essere implementate in modo tempestivo su numerosi dispositivi. Mentre gli OEM stanno cercando di implementare patch per i dispositivi, la dura verità è che la maggior parte di queste correzioni sarà limitata solo ai recenti flagship. Altri dispositivi non di punta e più vecchi, tanto meno quelli di OEM più piccoli, continueranno a essere esposti a prodotti simili a Stagefright.

C’è un lato positivo in questo exploit: Ha attirato nuovamente l'attenzione sul processo di aggiornamento di Android e lo ha presentato in una luce che non attirerà così tante future aziende verso l'adozione di Android per uso aziendale. Mentre Google lavora per una maggiore adozione da parte delle imprese, sarà costretto a riconsiderare la sua strategia di aggiornamento e la quantità di controllo che consente agli OEM.

Con Android M sempre più vicino al rilascio sul mercato, non sarebbe una sorpresa se Google decidesse di eliminare sempre più componenti di AOSP a favore del suo pacchetto di servizi Play. Dopotutto, questa è un'area su cui Google mantiene ancora il controllo completo se un dispositivo deve essere spedito con Google Play Store. Questo ha i suoi lati negativi sotto forma di sostituzione di aree open source con muri vicini.

Quando si specula sul futuro di Android, esiste una (molto piccola) possibilità che Google possa anche limitare le modifiche che gli OEM possono apportare ad AOSP. Con il quadro RRO essendo presente in uno stato funzionale in Android M, Google potrebbe limitare gli OEM ad apportare solo modifiche estetiche sotto forma di skin RRO. Ciò dovrebbe consentire una distribuzione più rapida degli aggiornamenti, ma a costo di negare agli OEM l’opportunità di personalizzare completamente Android.

Un altro percorso che potrebbe essere una possibilità sarebbe quello di renderlo obbligatorio per tutti i dispositivi con cui viene spedito Google Play Store per ricevere aggiornamenti di sicurezza garantiti per un periodo di tempo prestabilito, possibilmente due anni. Il framework Play Services potrebbe essere utilizzato per verificare la presenza di importanti aggiornamenti e patch di sicurezza, con la revoca dell'accesso al Play Store in caso di non conformità.

Note di chiusura

Nella migliore delle ipotesi si tratta ancora di speculazioni poiché non esiste un modo elegante per risolvere questo problema. A meno di un approccio decisamente totalitario, ci sarà sempre qualche lacuna nel raggiungimento delle soluzioni. A causa dell'enorme numero di dispositivi Android disponibili, tenere traccia dello stato di sicurezza di ciascun dispositivo sarebbe un compito davvero gigantesco. L'esigenza del momento è un ripensamento del modo in cui Android si aggiorna poiché il modo attuale non è certamente il migliore. Noi di XDA Developers speriamo che Android continui a rimanere fedele alle sue radici Open Source lavorando insieme ai piani closed source di Google.

Il tuo telefono è vulnerabile a Stagefright? Pensi che il tuo telefono riceverà mai una patch Stagefright? Fateci sapere nei commenti qui sotto!