hit counter
Security Advisory 943521 sulla gestione degli URI: non è colpa di IE 7 - NonSoloSecurity Blog di Feliciano Intini - Site Home - TechNet Blogs

NonSoloSecurity Blog di Feliciano Intini

Notizie, best practice, strategie ed innovazioni di Sicurezza (e non solo) su tecnologia Microsoft

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

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

  • Comments 7
  • Likes

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.

Comments
  • Come al solito articolo chiarissimo. C'è una cosa che non ho ben capito: come fa un applicativo, se fa _più_ controlli, ad espporre una vulnerabilità che un applicativo che ne fa _meno_ non espone?

  • Nel dubbio io ho scritto una patch provvisoria: <http://spacebunny.xepher.net/hack/shellexecutefiasco/>

  • @Blackstorm: + controlli = + codice, che prende un dato in input e lo elabora; se la gestione dell'input non è fatta con tutte le best practice del secure coding, c'è il rischio che ti scappi un buffer overflow.

    @ KJK::Hyperion: non avertela a male se ribadisco gli stessi concetti che tu stesso hai messo come premessa nella pagina in cui parli della tua patch provvisoria : le patch non ufficiali non possono garantire lo stesso livello di testing e qualità. Inoltre non possono garantire la sicurezza di quello che fa il codice di terze parti installato: posso immaginare la tua buona fede, ma chi mi garantisce che quello che mi fai installare sia sicuro ?

  • scusa la stupidità, ma quindi questo bug è il "solito" buffer overflow? E se si, se il processore che si usa ha la famosa "protezione da buffer overflow" (tipo athlon64) in abbinamento ad XP sp2 (mi pare sia chiamata"protezione esecuzione programmi), il tutto non si dovrebbe risolvere con il solo crash dell'applicazione senza nessun rischio di infezione x il sistema?

    Grazie :)

  • @ Zap: in realtà ho fatto l'esempio del buffer overflow per semplificare la spiegazione; l'indicazione riportata nell'advisory dice che l'informazione elaborata non viene maneggiata in modo sicuro, (indicazione generica che si può tradurre in diverse tipologie di vulnerabilità).

  • Ti ringrazio del chiarimento :)

  • Tra colleghi abituati a lavorare (ben) oltre l'orario di lavoro, quando uno di noi esce (peraltro legittimamente

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment