Michal Zalewski ci parla della sicurezza di Firefox

di Percy Cabello

Il mese scorso, Michal Zalewski, hacker molto conosciuto e autore del libro "Silence on the wire", ha scoperto alcune vulnerabilità di sicurezza presenti in Firefox 2 (alcune delle quali risolte nell'ultimo aggiornamento alla versione 2.0.0.2). Abbiamo fatto una chiacchierata riguardo al suo lavoro e alla sua opinione su Firefox e gli altri browser in generale.

Mozilla Links: Vedo che hai condotto ricerche su una serie di prodotti tra cui Internet Explorer, SendMail e, più recentemente, Firefox. Dal momento in cui scopri così tante vulnerabilità in un così breve periodo di tempo tendi a concentrarti per un po' su un prodotto specifico. E' corretto? Cos'è che attira la tua attenzione?

Michal Zalewski: Sì, e il motivo è abbastanza semplice: la mia attività di divulgazione pubblica di problemi di sicurezza è principalmente un hobby e non una professione e cerco di non limitarmi ad un'area troppo specializzata di competenze. Gioco con vari prodotti e tecnologie e quando ne trovo una interessante, la esamino per un paio di giorni o per delle settimane, a volte trovando alcune falle in rapida successione.

ML: Pensi di continuare ad analizzare Firefox e altri prodotti Mozilla per qualche tempo? Com'è stata finora l'esperienza di immergersi nel codice di Firefox?

MZ: Al momento sono occupato con un progetto privato. Comunque sì, è probabile che nelle prossime settimane farò ancora qualche ricerca sulla sicurezza del browser.

ML: A pensarci vado in confusione, c'è una metodologia che segui per scoprire vulnerabilità di sicurezza? Qualcosa in particolare in Firefox?

MZ: Ti concentri di solito su una conduzione particolare di test di sicurezza, e su un particolare tipo di vulnerabilità. Questo può essere fatto analizzando il codice alla ricerca di buffer overflow, testando in modo automatico un browser attivo alla ricerca di vulnerabilità del parsing HTML oppure controllando varie incongruenze nella gestione JavaScript, sulla base dei documenti pubblicati.

Alla fine, è tutta creatività... dopo tutto, stai cercando di scovare errori nel processo di pensiero di altre persone, ingegneri, sviluppatori; non è qualcosa che puoi formalizzare in corso d'opera.

ML: E' facile intuire le motivazioni di un hacker dal cappello nero (black hat hacker) alla ricerca di vulnerabilità di sicurezza. Cosa spinge invece un hacker dal cappello bianco (white hat hacker) come te?

MZ: Meglio che fare le parole crociate. Per molti ricercatori freelance si tratta di un interessante esercizio mentale e di una sfida allettante; per alcuni diventa un modo per guadagnarsi il pane quotidiano con mezzi legittimi, lavorando per i vendor di software.

L'etica della ricerca di vulnerabilità è un'altra storia. Non c'è dubbio che la divulgazione di problemi di sicurezza, in particolare quelli di scarso rilievo, ci aiuta a capire e proteggere meglio i nostri sistemi. La domanda è: stiamo aiutando i cattivi e se sì, questo dovrebbe essere un motivo per tenere segrete le informazioni?

E' una domanda a cui è difficile rispondere e non è sicuramente l'unica per quanto riguarda la sicurezza informatica; in modo analogo, potremmo chiederci se sia giusto insegnare pubblicamente il procedimento di una reazione nucleare a catena o qualunque altra tecnologia che possa avere un uso improprio. Lo spirito dell'open source e della piena divulgazione sono legati fra loro, e io approvo entrambi.

Alcuni vendor closed source tentano di sovvertire la libera divulgazione delle vulnerabilità di sicurezza equiparandola ad aiutare i terroristi e sostenendo che la colpa di tutti i problemi che vediamo oggi è dei ricercatori, e non della trascuratezza del loro codice. Da un lato è bello dare dare un preavviso ad un vendor disposto a collaborare e che è conosciuto per prendere seriamente in considerazione i problemi e risolverli rapidamente. Ma allora, anche avvisare immediatamente la comunità non è per forza una cosa negativa. Alla fine, vulnerabilità divulgate "in modo responsabile" si trasformano in exploit allo stesso modo (oppure, paradossalmente, più frequentemente*) delle vulnerabilità divulgate liberamente, quindi...

*Questo perché i vendor o le aziende che pagano per le vulnerabilità spesso richiedono exploit funzionanti per prendere seriamente in considerazione un problema di sicurezza. E indovinate cosa? Una volta scritti, è molto più probabile che gli exploit trapelino.

ML: Perché preferisci pubblicare liberamente vulnerabilità di sicurezza in luoghi come come la mailing list "Full Disclosure" invece di mantenere un profilo più basso e riportarle al team di sicurezza di Mozilla? Ti ho visto bazzicare su BugZilla e dunque non mi sembra una questione di "andare d'accordo". Questo ti esclude dal ricevere i premi che il team di sicurezza Mozilla offre a chi contribuisce alle vulnerabilità?

MZ: Quando si riportano vulnerabilità che non hanno un impatto immediato e profondo su Internet, non ci vedo nulla di male nel consentire una discussione pubblica del problema mentre il vendor sta lavorando ad una soluzione. Mi sembra una cosa giusta da fare, soprattutto perché non c'è davvero ragione di credere che non ci siano hacker dal cappello nero che abbiano scoperto il problema in modo indipendente e lo stiano utilizzando mirando a determinati utenti. Infatti, a volte ritrovo problemi che erano stati scoperti e relazionati in precedenza in modo "silenzioso" da amici ricercatori... ecco dove sta la soddisfazione, sono passati due anni senza alcuna risposta dal vendor!

In questo modo è possibile almeno rilevare l'attacco, oppure implementare delle contromisure.

Sono spesso bersagliato da Microsoft per la mia divulgazione pubblica ma devo ancora vedere una vulnerabilità da me riportata che si sia poi trasformata in un pericoloso attacco prima che fosse resa disponibile una patch correttiva.

I vendor open source hanno sensibilmente meno problemi riguardo alla divulgazione pubblica. Con Microsoft, non vengo nemmeno citati tra i riconoscimenti nei bollettini di sicurezza (perché non gliel'ho detto con sei mesi di anticipo). Con Mozilla, tutto questo non ti esclude dal premio per aver trovato una vulnerabilità: vogliono semplicemente che la gente li aiuti a rendere il loro browser più sicuro.

ML: Com'è stata l'esperienza di lavoro con gli sviluppatori Mozilla?

MZ: Molto positiva. A volte prendono decisioni di progettazione discutibili oppure nascondono vecchi problemi sotto al tappeto, come fa la maggior parte di noi... tutto sommato, sono molto aperti e disponibili a risolvere quegli errori, ed è questo che importa.

ML: L'anno scorso Mike Danseglio, program manager nel Security Solutions Group di Microsoft, ha detto: "Il phishing non rappresenta un problema di vitale importanza perché non c'è davvero soluzione alla stupidità umana". Ha ricevuto molte critiche ma, alla fine, è difficile non riuscire almeno a non sorridere di fronte a questo commento e ad altre opinioni analoghe.

MZ: Il problema è che, anche se non è possibile impedire agli utenti stupidi di farsi del male, è possibile fare molto di più per aiutare gli utenti più accorti nell'evitare di cacciarsi nei guai.

Ad esempio, la maggior parte dei prodotti tende ad inondare l'utente con avvisi ipercomplicati e difficili da capire, alla fine condizionando l'utente a cliccare sempre "OK" in qualunque finestra compaia. E allora gli utenti vengono ribattezzati "stupidi" per aver cliccato "OK" al milionesimo avviso che hanno davanti che, in 200 parole, non avverte loro di un inconveniente con un modulo o un certificato, ma suggerisce di installare un controllo ActiveX sulla macchina.

Oppure prendete tutte quelle barre gialle di avvertimento, una cosa che non sopporto davvero. Internet Explorer e Firefox a volte visualizzano un avviso su un plug-in da scaricare, degli aggiornamenti disponibili e finestre pop-up bloccate all'interno della finestra del documento. Il problema? Beh, finché tutto questo accade all'interno della finestra controllata dal documento, una pagina web malintenzionata può ingannare l'utente con il 100% di realismo. L'utente infatti non ha modo di sapere se il messaggio "Disponibile un aggiornamento per Firefox. Clicca qui per installare" oppre "E' richiesto un plug-in per visualizzare questa pagina. Scaricatelo qui" provenga dal browser o dall'autore del sito. L'utente potrebbe imbattersi in una serie di avvisi contraddittori dopo averci cliccato sopra. Come potrebbe mai saperlo lo zio Pinco Pallino? La progettazione di una pessima interfaccia non è colpa dell'utente. E non dobbiamo aspettarci che l'utente conosca la PKI e sia un abile sistemista per navigare in Internet.

ML: Gli sviluppatori sono responsabili della sicurezza del loro software fino al punto di patchare la negligenza di un utente? E' una questione economica?

MZ: Gli sviluppatori software dovrebbero garantire che le opzioni fornite all'utente siano di rado assolutamente necessarie, che siano presentate in un modo chiaro e conciso e che possano essere facilmente utilizzate per prendere decisioni informate.

Non è possibile impedire ad un utente imbranato di installarsi un controllo ActiveX pericoloso. Ma dovete permettere allo zio Pinco Pallino di sapere che sta scegliendo di infettare il proprio computer, senza il bisogno di utilizzare pagine di gergo tecnico o, ancora meglio, non chiederglielo neppure a meno che l'utente in precedenza non abbia capito che potrebbe aver bisogno di quella funzionalità.

ML: In un rapporto di un bug suggerisci di mantenere la barra degli indirizzi continuamente ben in vista, una strada che Internet Explorer 7 e Opera 9 hanno già preso. Hai altri consigli per gli utenti dei prodotti Mozilla?

MZ: Sì, alcuni, e la maggior parte non si riferiscono esclusivamente a Firefox, vedi ad esempio il problema della barra di notifica. Ma credo si tratti di un argomento per scrivere un libro intero.

ML: E' possibile etichettare un browser (immagino che questo valga per qualsiasi altra categoria, ma fermiamoci qui) più sicuro di un altro?

MZ: Direi che Lynx oggi è piuttosto sicuro. Oltre a questo... non vedo un browser così chiaramente superiore che abbia funzionalità paragonabili a Internet Explorer o Firefox.

Ringraziamo Michal per l'intervista che ci ha gentilmente concesso. Potete conoscerlo meglio visitando il suo sito web.