PDA

Visualizza versione completa : F-Secure: Firefox Cookie Bug


Giorgius
16-02-2007, 10.24.18
http://www.f-secure.com/weblog/archives/Bug370445.jpg

There's a new bug reported in the way Firefox handles writes to the 'location.hostname' DOM property. The vulnerability could potentially allow a malicious website to manipulate the authentication cookies for a third-party site. The bug was submitted by Michal Zalewski and was tested with the current version of Firefox...

Leggi: http://www.f-secure.com/weblog/

A demo of the vulnerability and a suggested work-around can be found here:

Test Bug: http://lcamtuf.dione.cc/ffhostname.html

Semi.genius
16-02-2007, 12.07.11
Uhm..se era di IE7, credo che in due ore questa pagina era piena :p

P8257 WebMaster
16-02-2007, 12.10.34
Uhm..se era di IE7, credo che in due ore questa pagina era piena :p

Eh si .. è proprio vero ..

[SARCASTIC MODE ON]
ma dal gruppo di ricerca hanno detto che non è un bug, è una feature... :devil:

[/SARCASTIC MODE OFF]

harman
16-02-2007, 12.44.55
E se fosse stato qui...
E se fosse stato lì...

:p

josefh♣
16-02-2007, 14.47.45
Michal Zalewski, noto ricercatore di sicurezza , ha segnalato e descritto due giorni fa una vulnerabilità di sicurezza critica in Firefox 2.0.0.1, la versione più recente del famoso browser open-source. Il problema di sicurezza interessa anche le versioni precedenti del software di Mozilla. La falla potrebbe consentire ad un sito malintenzionato di "impersonare" un sito autentico ed impostare per conto di quest'ultimo un cookie sulla macchina attaccata e nell'ambito di attacchi cross-window e cross-frame di compromettere le informazioni scambiate tramite Ajax.




Zalewski afferma nel suo advisory full-disclosure: "Esiste un seria vulnerabilità in Mozilla Firefox, verificata nella versione 2.0.0.1, che quasi certamente interessa tutte le più recenti versioni del prodotto. Il problema risiede nel modo in cui Firefox gestisce le scritture della proprietà

DOM 'location.hostname'. Tramite l'uso di uno script è possibile impostare questa proprietà ad un valore che non sarebbe altrimenti accettato come hostname durante il parsing di un URL regolare, includendo un stringa che contiene \x00. Facendo questo si provoca un particolare comportamento: internamente, le variabili stringa DOM sono NUL-terminated, e quindi la maggior parte dei controlli considerano un fantomatico 'evil.com\x00foo.example.com' come parte del dominio *.example.com. Il risolutore DNS, tuttavia, e gran parte del restante codice del browser, operano invece su stringhe ASCIZ native a C/C++, trattando l'esempio precedente come 'evil.com'. Questo permette a evil.com di modificare la proprietà location.hostname come descritto, ed inviare la richiesta HTTP risultante sempre a evil.com. Una volta caricata la nuova pagina, l'attacker sarà in grado di settare un cookie per *.example.com ed eventualmente manomettere il document.domain di conseguenza, in modo da bypassare la policy "same-origin" per XMLHttpRequest e accesso dati cross-frame/cross-window".

Zalewski ha anche reso disponibile una pagina di test che permette di verificare il funzionamento dell'exploit e la presenza della vulnerabilità nel browser. Dopo aver eseguito il PoC è possibile verificare l'esistenza del cookie coredump.cx (Strumenti – Opzioni – Privacy – Mostra Cookie). Per funzionare l'exploit necessita che il browser abbia Javascript attivo ed accetti cookie di sessione. Secondo Zalewski l'impatto di questa falla di sicurezza potrebbe essere alquanto grave: siti nocivi sono in grado infatti di manipolare i cookie di autenticazione di pagine third-party, e, bypassando la policy "same-origin", di modificare funzionamento e visualizzazione di questi siti.

Zalewski ha segnalato il problema al team Mozilla, che ha immediatamente aperto una pratica bug su BugZilla (370445). Nel giro di poche ore gli sviluppatori hanno già prodotto il codice necessario per la correzione del problema e poco fa il bug è stato segnato come "risolto" ed il fix è stato integrato nel trunk e nei rami di codice 1.8.0.10 e 1.8.1.2. Vista la gravità del problema, il fix sarà già reso disponibile con le imminenti "security release" per Firefox 1.5 e 2.0, rispettivamente gli aggiornamenti 1.5.0.10 e 2.0.0.2, attualmente previsti per il 21 Febbraio prossimo. In questo caso potrebbe esserci un ulteriore lieve delay sulla schedule di release considerato che il test sulle RC non aveva evidenziato stopper bug e che era già stato avviato il processo di realizzazione delle build l10n.

Nel frattempo il team di Mozilla suggerisce un workaround temporaneo di protezione: Digitate about:config nella barra degli indirizzi per accedere alle preferenze avanzte del borwser; Cliccate con tasto destro del mouse su qualsiasi voce e selezionate Nuovo->Stringa; Scegliete capability.policy.default.Location.hostname.set come nome dell'impostazione; Inserite come valore noAccess; Riavviate Firefox.

Ricordiamo che dopo 1/2 settimane dal rilascio di Firefox 1.5.0.10 e 2.0.0.2, Mozilla offrirà anche, agli utenti Firefox 1.5.x, il "major upgrade" automatico alla versione 2.0.x del browser. Attualmente infatti gli utenti Firefox 1.5.x che vogliono eseguire l'upgrade devono necessariamente scaricare ed installare manualmente Firefox 2.0.x. Mozilla ha già da tempo annunciato che Firefox 1.5.x sarà supportato solo fino al 24 Aprile prossimo, successivamente non saranno più rilasciati aggiornamenti di protezione e stabilità per questa versione del prodotto.


Pagina di test (http://lcamtuf.dione.cc/ffhostname.html)

Pratica bug su Bugzilla (370445) (https://bugzilla.mozilla.org/show_bug.cgi?id=370445)

"major upgrade" (http://wiki.mozilla.org/Major_Update_1.5.0.x_to_2.0.0.x)

Gergio
16-02-2007, 14.56.28
(unite le discussioni)