19/05/2009 di Redazione

Chrome, la sicurezza del browser di Google

Con un intervista a due specialsti, cerchiamo di capire cosa si nasconde dietro i sistemi di sicurezza di Chrome, il browser di Google.

immagine.jpg

Introduzione

Continuiamo la nostra serie di articoli sulla sicurezza, questa volta con un'intervista a Collin Jackson e Adam Barth per parlare della sicurezza di Google Chrome. Entrambi sono membri del Web Security Group della Stanford University. Collin al momento sta finendo il suo dottorato, mentre Adam ha completato da poco sia quello che un master, e ha poi completato la sua formazione a Berkley.

Hanno lavorato per Google, occupandosi di fornire un'analisi dettagliata dell'architettura di sicurezza di Chrome, vale a dire Chromium. Il motore di rendering di Chrome è considerato il più sicuro in circolazione, in particolare grazie alla sandbox, che lo isola dal sistema operativo, evitando la maggior parte dei potenziali pericoli.


Collin Jackson

TH: Cominciamo dalle basi, parlateci un po' di voi, di come avete deciso si specializzarvi nel campo della sicurezza, e di come avete scelto entrambi l'Università di Stanford.

Collin: Andai a Stanford perché ha i migliori docenti in diversi campi, anche se non ero certo di quale settore avrei scelto. Quando arrivai, la sicurezza del Web richiamò la mia attenzione perché mentre cresce lo sviluppo e l'interesse per il cloud computing e le applicazioni online, la ricerca e lo sviluppo dei protocolli di sicurezza Web è ancora indietro.

Adam: A me invece interessa la sicurezza da quando ero un ragazzo. Uno dei miei giochi favoriti, da piccolo, era inventare codici cifrati da proporre ai miei amici. Scelsi Stanford perché sono cresciuto a Palo Alto, e mia madre è un'insegnante alla Facoltà di Economia.


Adam Barth

TH: Qual è stato l'aspetto più interessante nel lavorare per Google?

Adam: Per me la cosa migliore del lavoro per Google è stata la possibilità di usare la loro incredibile infrastruttura di calcolo. L'abbiamo sfruttata per ottimizzare la sicurezza dell'algoritmo che analizza i contenuti, in Chrome.

TH: alcuni sviluppatori hanno abbandonato Google, perché trovavano il processo burocratico troppo complesso e invasivo. È stato difficile convincere l'azienda a permettervi di svolgere il vostro esperimento, e a sfruttare il database di Google, che include milioni di pagine web? Poi li avete anche convinti a coinvolgere altro personale per testare manualmente i 500 siti più rilevanti. Quanto ci è voluto a completare tutti i test sul vostro algoritmo?

Adam: Non abbiamo dovuto affrontare particolari resistenze per svolgere il nostro esperimento. Non saprei dire con certezza quanto ci è voluto, ma è stata certamente più veloce la sperimentazione che lo sviluppo del codice. Abbiamo fatto questo lavoro pensato al processo di standardizzazione HTML 5, e speriamo che i nostri risultati possano servire anche agli sviluppatori di altri browser.

Viaggio al cuore di Chrome

TH: Al momento come sono configurati i vostri computer, e quali browser usate regolarmente?

Collin: cerco di non fare favoritismi, e di usare allo stesso modo IE, Firefox, Safari, Chrome e Opera. Uso un MacBook con XP virtualizzato tramite VMWare, ma ho anche una macchina con Vista e una con Ubuntu, che uso alternativamente.

Adam: ho diversi computer, ma il mio favorite è il Mac Mini, perché è piccolo e silenzioso. Quanto ai browser, uso soprattutto Chrome 2 beta, ma recentemente ho usato anche IE8, per provarne le novità.

TH: Vorremmo saperne di più sulle funzioni di sicurezza di Chromium. Vi hanno chiesto solo di farne un'analisi, o siete stati coinvolti anche nel processo di sviluppo?

Adam: quando ci siamo uniti al progetto era già stato stabilito che si sarebbe sfruttato il principio della sandbox. Ma chiudere il motore di rendering un una scatola non è abbastanza, per la sicurezza. Bisogna concentrarsi anche sul collegamento tra il kernel del browser e il motore di rendering: per esempio, come permettere all'utente di caricare file su un sito web senza permettere al motore di leggere file arbitrari? È il genere di cose sulle quali ci siamo concentrati.

TH: Quali erano gli obiettivi di Chromium dal punto di vista della sicurezza?

Collin: L'architettura di Chromium è progettata per difendersi dal malware, dalla sottrazione di file, e dal keylogging, nel caso ci sia una qualche vulnerabilità nel motore di rendering. Chromium ha anche delle caratteristiche di sicurezza  che rispettano gli standard industriali, sia per il malware che per il phishing, come il Safe Browsing e la Extended Validation. In Google Chrome queste funzioni sono completate da un meccanismo d'aggiornamento automatico, che permette a Google di rilasciare velocemente gli aggiornamenti necessari.

TH: I nostri lettori conoscono la differenza tra applicazioni multi-threaded e single-threaded, e del loro valore quando si parla di prestazioni. Chromium è sviluppato per occupare processi multipli: questa scelta è legata alla sicurezza, piuttosto che alle prestazioni?

Adam: Separando il browser in diversi processi Chromium può sfruttare le funzioni di sicurezza del sistema operativo per attivare la sandbox e "metterci" il motore di rendering. La separazione dei processi, poi, rende più chiara l'interfaccia tra i componenti, che possono interagire solo tramite un canale limitato e controllato.

Sotto la sabbia

TH: Quindi anche se un intruso riuscisse a compromettere il motore di rendering, non potrebbe aggirare la limitazione alla scrittura di file, proprio per i limiti stessi del motore di rendering. A meno che il pirata riuscisse, allo stesso tempo, a superare anche le protezioni di Windows. È corretto?

Collin: La minaccia sarebbe contenuta e limitata al processo di rendering, il che rappresenta un grande passo avanti, rispetto alle macchine del tutto "bucate" che vedevamo in passato. Il motore di rendering, tuttavia, è l'elemento che garantisce l'isolamento, quindi se viene compromesso l'attaccante potrebbe tentare di superare la barriera.

TH: Che cosa s'intende per isolamento?

Collin: Con alcune eccezioni, le applicazioni Web devono leggere dati solo dal server di riferimento. La sandbox evita che un attacco proveniente da, per esempio, attacco.org  possa leggere i dati di altri server, per esempio quello di Gmail. Però una singola istanza del motore di rendering potrebbe aver bisogno di accedere a diversi server, e per questo Chromium permette di creare eccezioni alla politica d'isolamento.

TH: Cosa succede quando si esegue Chrome con plug-in "sicuri"?

Adam: i plug-in sicuri sono un'opzione sperimentale che permette a Chrome di gestire plug-in(come Flash Player o Windows Media Player) all'interno della sandbox. Chiudere un plug-in nella sandbox aiuta a ridurne le potenziali vulnerabilità, ma potrebbe anche compromettere alcune funzioni, come, per esempio, l'aggiornamento automatico.

TH: per godere delle migliori prestazioni di sicurezza, gli utenti devono usare Windows Vista con un file system NTFS. Che cosa rende l'abbinamento XP/FAT32 più vulnerabile?

Adam: il sile system FAT32 non prevede una lista di controllo, quindi Windows non può impedire al motore di rendering di accedere al disco in scrittura. Le altre differenze, invece, sono più che altro delle sfumature, dal punto di vista della sicurezza.

TH: Come può Chromium essere compatibile con le funzioni web per caricare file? Che succede se la sandbox, che separa il motore di rendering dal kernel del browser, viene violata?

Adam: Per gestire l'upload dei file abbiamo sfruttato una procedura quasi classica. Il kernel del browser mostra una finestra di dialogo per scegliere il file da caricare, e tiene traccia del file selezionato. Quando il motore di rendering fa una richiesta simile, in un secondo momento, il kernel ricontrolla il file, per accertarsi che si tratti di quello selezionato. Senza questa procedura di controllo, un motore di rendering compromesso potrebbe leggere dati diversi e, potenzialmente, trasferirli ad un malintenzionato.

TH: Perché limitarsi al motore di rendering e al kernel del browser? Perché non dividere Chrome in diverse sandbox, così da avere sotto controllo anche altri elementi come la gestione delle finestre o i cookie?

Collin: usare diverse sandbox per "spezzettare" il browser non è un'impresa a costo zero: si farebbe sentire sulle prestazioni, e rappresenterebbe una mole di lavoro immenso per gli sviluppatori che si occupano del mantenimento. Un componente racchiuso in una sandbox, inoltre, è tanto potente quanto la sua interfaccia, che quindi deve essere progettata  con molta cura, per accertarsi che non sia a sua volta vulnerabile. Nonostante queste difficoltà, credo che in futuro vedremo crescere l'adozione della procedura di "sandboxing", e sono contento che ci siano ricercatori al lavoro.

La concorrenza

TH: tra i browser sviluppati nei laboratori di ricerca c'è DARPABrowser, che fa parte di un contratto con la DARPA (Defense Advanced Resarch Project Agency). Disabilitando Javascript, Chrome potrebbe offrire la stessa sicurezza?

Adam: il DARPABrowser ha obiettivi di sicurezza molto diversi da Chromium: per esempio, deve limitare i danni che possono derivare da un motore di rendering compromesso, quando si visualizza una pagina "pulita". Per cercare di risolvere tanti dettagli simili, si rendono complessi gli elementi che hanno un qualche privilegio, tanto da farli somigliare allo stesso motore di rendering. Però non è chiaro quanta sicurezza in più si ottiene, con tanto lavoro.

TH: parliamo dei browser disponibili pubblicamente. In cosa la Modalità Protetta di Internet Explorer è diversa da quello che fa Chromium.

Collin: la Modalità Protetta è pensata per proteggere i file da sovrascritture non autorizzate. È un buon punto di partenza, perché rende più difficile l'installazione di malware, ma lascia la possibilità di leggere i file. Si tratta di un elemento importante, e l'architettura di Chromium è pensata per garantire la confidenzialità e la sicurezza delle informazioni archiviate sul computer.

TH: Opera, da parte sua, supporta NX e ASLR, funzioni supportate anche da IE8. Sono presenti anche in Chromium?

Adam: Sì, Chromium usa NX, ASLR e StackCheck.

TH: Mac OS X offre meno funzioni di sicurezza rispetto a Windows Vista o Windows 7, ma è considerato generalmente più sicuro perché esistono meno minacce al sistema. Dino A. Dai Zovi ha fatto il paragone della porta di casa lasciata aperta: non è implicitamente insicuro, dipende da dove vivi. Quali sfide rappresenta lo sviluppo di Chromium, e della sua sandbox, su Mac OS X o Linux?

Adam: Mac OS X integra un potente dispositivo di sandboxing, che Chromium può sfruttare per creare la sandbox che gli serve. Ci sono alcune sfide legate alla molteciplità dei processi, ma sono certo che salterà fuori una soluzione. Tra le varie distribuzioni di Linux ci sono differenze, per quanto riguarda la procedura di sandboxing, come SELinux o AppArmor. Il team che si occupa di sviluppare Chrome per Linux sta valutando quali di queste soluzioni è quella più adatta.

I prossimi passi

TH: Google ha scelto per Chromium la strada dell'open-source, nella speranza che altri adottino il suo modello si sicurezza. La collaborazione è uno strumento molto utile e potente, ma può anche rappresentare una difficoltà. Quali altri modelli di sicurezza sono stati presi in considerazione, oltre al sandboxing?

Collin: per ridurre le vulnerabilità è anche possibile ricorrere più massicciamente al codice managed (che ha bisogno di un ambiente dedicato per essere eseguito). I motori di rendering sono incredibilmente complicati, ma devono essere anche veloci, e quindi è probabile che ci si trovi del codice "selvaggio" (unmanaged), all'interno della sandbox. Il kernel del browser, però, può essere reso piuttosto semplice, se lo si inserisce in ambienti come Java o .NET, e si ottiene protezione su entrambi i lati della sandbox. C'è una ricerca Microsoft, Gazelle, che va in questa direzione.

TH: Siamo certi che raccomandereste Chrome per gli utenti Windows, ma cosa direste agli utenti Mac e Linux?

Adam: preferisco limitarmi a raccomandare un aggiornamento a chi usa ancora IE6.

TH: quali browser state usando al momento?

Adam: sul mio Mac Mini di solito uso Firefox, perché spesso uso una versione di sviluppo di Safari/WebKit, che può creare un po' di confusione se lo si usa anche per Gmail. Se invece devo fare il debugging per Firefox, uso Safari od Opera.

Collin: è una situazione comune, anche per me. Uso tutti i browser, a meno che non mi trovi in situazione di debugging, perché non mi piace riavviare.

TH: Visti i vostri curriculum, che cosa consigliereste a chi vuole intraprendere una carriera nell'informatica?

Collin: prendere contatto con la comunità e con il software reale è importante, e per farlo partecipare a progetti open-source è un'ottima idea. È persino possibile guadagnare qualcosa, grazie a Google: Summer of Code (http://code.google.com/soc/). Per quest'anno le iscrizioni sono chiuse, ma tenetelo a mente per l'anno prossimo.

scopri altri contenuti su

ARTICOLI CORRELATI