Security Advisory 943521 sulla gestione degli URI: non è colpa di IE 7

Scrivo questo post per avvisarvi dell'emissione del Microsoft Security Advisory 943521 e per tentare di aiutarvi a capirci qualcosa in questo affollarsi di notizie rispetto alle vulnerabilità vere o presunte di Internet Explorer e dei cosiddetti Application Protocol handlers. A dire la verità questo tentativo lo ha già provato il blog del MSRC con l'attuale post in home page (che vi consiglio comunque di leggere): ma visto che ci ho messo un po' per recuperare il bandolo della matassa ho pensato che non faceva male cercare di spiegare le cose in modo ancor più semplice.

Ci sono due situazioni distinte, entrambe però correlate a questi benedetti Application Protocol handlers. Serve quindi un minimo di idea di cosa siano e la potete acquisire in questo post del blog di IE: in breve, tramite l'uso di un prefisso in un URL siamo in grado di lanciare una nuova applicazione e di passargli dei parametri ("http:" lancia il browser,"mailto:" lancia il client di posta, ecc.).

La prima situazione. Lo scorso giugno/luglio c'è stata una querelle tra Microsoft e Mozilla su un problema di sicurezza che coinvolgeva una interazione tra IE e Firefox: navigando con IE era possibile far eseguire del codice arbitrario all'interno di Firefox (su un sistema Windows dotato di entrambi i browser), grazie alla possibilità di lanciare Firefox come URL protocol handler e di passargli un URL malformato. Mozilla diceva: è colpa di IE che non verifica l'URL che passa a Firefox. Microsoft rispondeva: non posso controllare io quello che passo agli Application Protocol handlers perché non conosco come come sono fatti e non voglio creare problemi di compatibilità applicativa (magari loro usano una codifica particolare per attivare una funzionalità e se la blocchiamo a priori finiamo bloccare un flusso di dati lecito), è responsabilità del programma finale quella di validare i dati ricevuti in ingresso prima di elaborarli (sacrosanto direi). Una spiegazione di maggior dettaglio la trovate su questo post di Jesper Johansson (un ex security guru di Microsoft, un mito che vi consiglio di seguire) e in grado convincervi in modo ragionevole che in questo caso Microsoft aveva ragione.

La seconda situazione. Se "zoommiamo" in questo passaggio della patata bollente (l'URL malformato) da IE all' Application Protocol handler scopriamo il componente di Windows che chiama di fatto l'applicazione finale: è la funzione di Windows chiamata ShellExecute(). Quando su Windows XP e Windows Server 2003 è presente IE6, la patata bollente viene passata toccandola il meno possibile. Quando invece su queste versioni di Windows (Windows Vista non è interessato da questa vulnerabilità) c'è Internet Explorer 7 allora avviene un processo ulteriore di validazione della correttezza degli URL: sia IE 7 che la funzione ShellExecute() cercano di pulire un pochino la patata bollente prima di passarla all'applicazione finale. Peccato che la funzione ShellExecute() non abbia i guanti perfettamente termici e ci sia il rischio di ustionarsi: questo è il bug di Windows segnalato nell'advisory che verrà corretto da una patch in fase di realizzazione. Windows Vista ha la funzione ShellExecute() con i guanti ben termici rispetto a questo aspetto, e non si ustiona. Se notate, questa situazione non contraddice l'assunto sacrosanto che ho sottolineato nel paragrafo precedente: con IE 7 a bordo,  Windows XP/2003 fa più controlli, quindi elabora, e non facendolo correttamente (bug nella validazione) espone una vulnerabilità (di Windows, non di IE). 

Ci tenevo a chiarire questi aspetti per dissipare l'errata percezione che sia IE 7 ad essere affetto dal bug e che quindi invece di fare passi avanti si stiano facendo passi indietro: la presenza di IE7 mette solo in evidenza un bug di Windows nelle versioni precedenti a Windows Vista.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS