A quanto pare, la sicurezza non è la principale caratteristica dei tre programmi Microsoft che mettono a disposizione degli utenti di Windows i più importanti servizi della Rete.

Le versioni 5.0 e 5.5 del browser Internet Explorer sono afflitte da un "baco" nella gestione delle estensioni MIME: in particolare, il browser ne valuta il contenuto in base al MIME type dichiarato, ma le gestisce secondo quanto indicato dall'estensione del file che ne costituisce il reale contenuto.

Ciò significa che è possibile ingannare IE fingendo che il contenuto della sezione MIME sia innocuo (ad esempio un file "wav", il cui MIME type è audio/x-wav), ma inserendovi "fraudolentemente" un programma o un comando batch. Il browser, tradito dal tipo dichiarato, che di per sè non suscita sospetti, gestisce l'allegato come suggerito dalla sua estensione (.exe o .bat), senza avvisare l'utente: in buona sostanza, lo esegue.

Si tratta di un problema particolarmente grave in quanto non riguarda solamente, come potrebbe sembrare a prima vista, gli allegati alle email: il discorso non cambia se la sezione MIME fa parte di una pagina HTML (o, più precisamente, EML). In altre parole, è sufficiente visitare con IE una pagina web costruita in modo "malizioso" perché sul computer dell'utente siano eseguiti, a sua completa insaputa, i comandi predisposti dall'autore del sito, con implicazioni facilmente intuibili.

Non ci credete? Allora vi indico un esempietto molto interessante... e, già che ci siamo, anche la patch.

E veniamo a IIS. Sotto accusa, questa volta, è l'algoritmo di parsing degli URL. IIS, come del resto tutti gli HTTP server, effettua il parsing dell'URL richiesto per ricondurlo alla cosiddetta "forma canonica" e, successivamente, verifica che non "conduca" a files ai quali non deve essere consentito l'accesso. In particolare, gli URL che referenziano programmi CGI o server-side scripts non devono "risalire" a directories esterne alla porzione di filesystem prestabilita in configurazione. A fini di validazione sono risolte e verificate anche le sequenze di escape, che consentono di inserire negli URL qualsiasi carattere, rappresentandolo mediante il suo codice ASCII esadecimale preceduto da "%".

Dove sta il problema? IIS, dopo avere effettuato parsing e validazione, effettua un secondo parsing, ma non un ulteriore controllo di liceità. Ciò rende possibile referenziare files sparsi ovunque nel filesystem della macchina proprio tramite le sequenze di escape: utilizzandole per codificare in un URL i caratteri che compongono altre sequenze di escape, queste ultime vengono risolte dal secondo passaggio di parsing: il vero URL risultante a questo punto è acceduto senza essere validato. Con tale tecnica, non è difficile inserire pathnames arbitrari nell'URL di una richiesta script o CGI e forzare IIS ad eseguire qualsiasi programma sia installato sulla stessa macchina. Sono disponibili le patches per le versioni 4.0 e 5.0 di IIS, entrambe colpite dal problema.

Infine, due parole su Outlook. Microsoft ha rilasciato recentemente un nuovo controllo ActiveX, denominato "Microsoft Outlook View Control", accessibile dagli scripts a causa di un errore nella certificazione: esso è infatti marcato "safe for scripting" mentre, per le sue caratteristiche implementative, non dovrebbe esserlo. Il risultato è che script inseriti nei messaggi email possono eseguire, attraverso detto controllo ActiveX, comandi e programmi all'insaputa dell'utilizzatore.

Al momento, non pare che esista una patch specifica per il "Microsoft Outlook View Control". Ci si può difendere installando i security service packs messi a disposizione da Microsoft per Outlook 2000 e 98, oppure disabilitando l'esecuzione degli scripts nelle email.

Tirando le somme, la situazione appare sconfortante: si tratta di problemi di gravità notevole, e non stiamo parlando di programmini qualsiasi, ma di Software Blasonato (nonché Costoso e Diffuso). E certo non ci rallegra la patetica affermazione con cui Microsoft, nel proprio bollettino dedicato al problema di IE sopra descritto, ne minimizza la portata: "Perché l'attaccante possa colpire con successo l'utente sfruttando questa vulnerabilità, è necessario che riesca a persuaderlo a visitare una pagina web da lui controllata o ad aprire una email da lui spedita".

Ogni commento è superfluo.

Hai a disposizione ancora caratteri. Per inserire commenti più lunghi (e senza CAPTCHA), iscriviti.
Il tuo nome:		La tua email: