Safari crollato al Pwn2Own: la sicurezza degli utenti Apple è a rischio?

Immagino molti di voi abbiano sentito parlare del Pwn2Own, la competizione annuale tra ricercatori di sicurezza (hackers, o anche white hat per distinguerli dai crackers, o black hat, che sono i “malintenzionati”) che si svolge nel corso della conferenza CanSecWest. Il Pwn2Own 2011 è attualmente in fase di svolgimento, a Vancouver, e durerà fino all’11. Ma già ieri sono arrivati i primi interessanti risultati: sia Safari che Internet Explorer sono crollati sotto i colpi degli exploit preparati con cura dai team in gara.

pwn2own

Condizioni? Vediamo come si svolge la competizione: la vittima designata per Apple è un MacBook, per Microsoft un notebook non meglio identificato. I sistemi sono equipaggiati rispettivamente con:

  • Mac OS X Snow Leopard (10.6.6) a 64-bit e Safari 5.0.3 (difficile fosse già stato portato alla 5.0.4, ma come vi spiegherò dopo è sostanzialmente ininfluente)
  • Windows 7 (Service Pack 1) a 64-bit e Internet Explorer 8 (essendo ancora in Release Candidate al momento del contest, Internet Explorer 9 non può essere sfruttato per la competizione, poiché vengono utilizzati solo rilasci stabili).

Obiettivo? Bucare i browser e i sistemi operativi aggirando le protezioni anti-exploit poste al loro interno, ossia la Data Execution Prevention (DEP), che lavora sia a livello di sistema che di processore, e l’Address Space Layout Randomization (ASLR), che carica in memoria i processi in indirizzi casuali di memoria per non fornire informazioni precise al malintenzionato su dove attaccare. Il DEP è presente in maniera completa sia su Mac OS X che su Windows, mentre l’ASLR è presente su Windows in forma completa e su Mac OS X, almeno per quanto riguarda Snow Leopard, in forma parziale (Lion, vista l’attenzione chiesta da Apple agli esperti di sicurezza, si suppone l’abbia completo). Era necessario sfruttare vulnerabilità non conosciute dei browser, bypassare queste protezioni a livello di sistema operativo e fare in modo di eseguire da remoto l’applicazione Calcolatrice e creare un file nel disco rigido.

I premi? $15.000 sia al primo che bucava Safari che al primo che bucava Internet Explorer, più un MacBook Air da 13” in palio per chi bucava Safari e un portatile di marca non meglio specificata per chi bucava Internet Explorer. Da notare che gli exploit non vengono creati al momento. Di solito i più bravi li hanno già approntati con cura qualche tempo prima, in modo da essere pronti a sferrare il colpo al Pwn2Own nel più breve tempo possibile. Ricordate: per vincere non è importante solo “bucare”, ma anche riuscirci prima di tutti gli altri.

Iniziamo rompendo gli indugi: il primo a crollare è stato Safari per mano del team di sicurezza francese VUPEN, che ha preparato l’exploit nel giro di due settimane. In quel lasso di tempo è stata scoperta la vulnerabilità di tipo zero-day (più in là spiegherò nel dettaglio cosa significa) ed è stato sviluppato il codice per effettuare l’exploit. La cosa che più ha colpito è che ci è voluto più tempo per creare il codice “maligno” che non per trovare la vulnerabilità. Come dichiarato da VUPEN, quella è stata la parte minore. A complicare la scrittura dell’exploit è stata la scarsa documentazione riguardo l’argomento relativamente a Mac OS X a 64-bit (meglio documentata, invece, la versione a 32-bit). Di fatto il codice è stato scritto da zero, tentativo su tentativo, finché non si è raggiunto il risultato sperato.

Come ha funzionato l’exploit? Safari dirottato su un sito compromesso ad-hoc e in 5 secondi la Calcolatrice era già aperta. Ma la sorpresa più interessante arriva adesso: la vulnerabilità non è di Safari, ma del motore di rendering WebKit. Il che significa che in linea teorica, anche Chrome potrebbe condividere la stessa vulnerabilità. Tuttavia la sandbox del browser di Google rende le cose molto più difficili rispetto alle condizioni di Safari.

E Internet Explorer? Prima di proseguire vediamo cosa è successo con il browser di Microsoft. Il ricercatore irlandese Stephen Fewer ha bucato Windows in modo non molto dissimile a quanto visto per Mac OS X. Ma se per Safari è bastata una unica grande vulnerabilità, per Internet Explorer 8 è servita una combinazione di tre piccole vulnerabilità. Ed è stato necessario sfruttarle tutte e tre in modo preciso e coordinato per avere successo con l’attacco. E non solo, la sandbox con cui è fatta la Modalità Protetta di Internet Explorer 8 ha dato pane per i denti di Fewer: ci sono volute ben 6 settimane per bucare il browser ed il sistema. Anche in questo caso la parte difficile è stata creare l’exploit, ma non per assenza di documentazione (abbondante su Windows) piuttosto per la coriacea protezione fornita dalla già citata Modalità Protetta, che ha richiesto un sacco di tempo e risorse per essere bucata.

Bene, ora direte: se anche Internet Explorer è stato bucato, perché fai apparire come se Safari se l’è cavata peggio? Basta guardare come è avvenuto il tutto. Safari: due2settimane, un grande e grosso bug. Internet Explorer: 6 settimane, tre bug che per essere sfruttati è stato necessario “collegarli in serie”. Inoltre, considerate anche altri fattori: Safari non ha una vera e propria sandbox protettiva e Mac OS X Snow Leopard non ha una forma completa dell’ASLR (il che rende la sandbox fornita dal sistema tutto fuorché invulnerabile). La maggiore difficoltà non è stata bypassare, ma l’assenza di documentazione sufficiente. La conseguenza del tutto è una conferma di quanto già affermava in precedenza Charlie Miller: Safari ha ancora molti passi da compiere in ambito sicurezza.
Possibile obiezione: sicuramente hanno provato Safari 5.0.3, non c’è stato il tempo materiale di usare la 5.0.4, magari hanno già sistemato il tutto. Risposta: no, non è possibile. Il perché è presto detto: queste falle, chiamate zero-day, non sono note agli sviluppatori del browser, ma solo a coloro che le hanno scoperte, che siano benintenzionati o malintenzionati. Dunque è deducibile che la 5.0.4 sia ancora esposta a questa vulnerabilità. Così come, molto probabilmente, Internet Explorer 9 in ambito Windows, che uscirà fra pochi giorni (14 Marzo).

Fortunatamente per gli utenti ci sono buone notizie: la prima è derivata dal fatto che le vulnerabilità sono state scoperte da ricercatori di sicurezza e non da criminali, il che assicura almeno per un po’ l’impossibilità di sfruttarle da parte di malintenzionati. La seconda buona notizia è che subito dopo la fine della competizione le vulnerabilità saranno rese note ad Apple e Microsoft, consentendo così l’inizio dei lavori sulle apposite patch. La terza buona notizia, per gli utenti Apple, è che Safari in Lion presenta WebKit2, che prevede la separazione delle tab in singoli processi e un più efficace modello di sandbox. La quarta buona notizia è che, come scritto più sopra, con Lion Apple sembra aver prestato molta più attenzione alla sicurezza e molto probabilmente è stata anche completata l’implementazione dell’ASLR. Ciononostante quanto è successo ieri merita comunque un po’ di riflessione sull’azienda di Cupertino. Attualmente non c’è grande interesse ad attaccare Mac OS X, per vari motivi di cui è meglio non dilungarsi perché spesso portatori di discussioni roventi, ma se un giorno si iniziasse a fare sul serio? Come si ritroverebbe l’utente Apple? Come si potrebbe poi giustificare quello che era uno dei principali “selling points” di Mac OS X, ovvero l’assenza (o bassa presenza) di problemi di sicurezza?

Sono domande che è necessario si pongano a Cupertino. E con Lion qualcosa sembra che stia iniziando a cambiare.
Sveglia Apple: la sicurezza non è uno scherzo.

Giovanni "il Razziatore"

Deputy - Ho a che fare con i computer da quando avevo 7 anni. Uso quotidianamente OS X dal 2011, ma non ho abbandonato Windows. Su mobile Android come principale e iOS su iPad. Scrivo su quasi tutto ciò che riguarda la tecnologia.

Commenti controllati Oltre a richiedere rispetto ed educazione, vi ricordiamo che tutti i commenti con un link entrano in coda di moderazione e possono passare diverse ore prima che un admin li attivi. Anche i punti senza uno spazio dopo possono essere considerati link causando lo stesso problema.