Biscotti avvelenati per il pandino rosso

L'esperto di sicurezza Michael Zawleski ha scoperto un bug nella gestione dei cookie in Mozilla Firefox che potrebbe permettere a siti malevoli di bypassare le restrizioni di sicurezza impostate nel browser con la possibilità di manomettere i cookie degli altri siti nonchè modificare il modo in cui questi ultimi vengono visualizzati.

Qui è possibile testare la vulnerabilità. Il bug è stato corretto e probabilmente il fix verrà inserito nella versione 2.0.0.2 di prossima uscita. Per il momento è fortemente consigliato l'uso di Noscript di Giorgio Maone (italian developer :-D, autore anche dell'ottima FlashGot).

Su mozillalinks viene suggerita anche un'impostazione avanzata di policy per mettere una pezza alla vulnerabilità

AGGIORNAMENTO: ho eseguito il test con il mio profilo abituale e non avendo abilitato l'accettazione dei cookie da quel sito l'exploit fallisce (uso CookieSafe per gestire agevolmente i permessi). La prima volta avevo provato con un profilo pulito ed era andato a buon fine.

Impostando la preferenza di tipo stringa:

capability.policy.default.Location.hostname.set

a noAccess come suggerito su mozillalinks questo è quello che mi appare se tento di eseguire l'exploit:

Permesso negato

Quella preferenza non sarà (anche se presente nel file prefs.js) visibile dall'about:config e per rimuoverla dovrete (previo backup) editare a manina il prefs.js e cancellarla. La spiegazione del perché quella preferenza è nascosta con about:config la trovate su Mondozilla (commento numero due di prometeo)

AGGIORNAMENTO 2: per utenti Seamonkey inserire le seguenti linee nel file all.js che nel mio caso si trova in:
C:\Programmi\mozilla.org\Seamonkey\greprefs\

// CAPS Zawleski bug fix
pref("capability.policy.default.Location.hostname.set","noAccess");

tale preferenza avrà effetto in tutti i profili in uso. Seamonkey ha una gestione più avanzata dei cookie rispetto a Firefox, dunque, se non volete fare la modifica al file all.js potete sempre impostare Seamonkey in modo che vi chieda ogni volta l'autorizzazione per memorizzare i cookie.

Fonti: Bugzilla,Proof of concept, mozillalinks, Mondozilla.

10 Responses to “Biscotti avvelenati per il pandino rosso”


  • Perfetto!
    Prima il mio PC era vulnerabile, dopo il Noscript di Giorgio Maone mi compare in basso una scritta "esecuzione script attualmente vietata [<script>;6][J+F+P;O]".
    Penso che ci siamo, in attesa di FF2.0.0.2!

  • Ho aggiornato il post, in effetti io uso più di un profilo utente e su quello standard che uso per la navigazione l'exploit funzionava, provando su quello configurato in modo un po' più ristretto invece no perché non avevo abilitato l'accettazione dei cookie (biscotti) dai siti (ho una white list).
    Ciao

  • Cavoli! Una vlnerabilità mica da poco! 😕

  • In effetti questa è abbastanza grave, speriamo esca presto la versione 2.0.0.2 :-).

  • Vulnerabilità FF 2.0.0.1 riscontrata anche in ambiente linux. Installato Noscript, mi è comparso in basso lo stesso prompt 'esecuzione script attualmente vietata' e anche qui dovrei essere a posto.
    Chiedo ad Andrea Micheloni, ma anche su Linux il mancato blocco di script sarebbe una "Una vulnerabilità mica da poco"?
    Ciao

  • Beh, diciamo che è una vulnerabilità multipiattaforma 😀
    La sua pericolosità, se ho ben capito, è data dal fatto che un qualunque sito può scrivere i cookie a un altro dominio, senza l'autorizzazione dell'utente.
    Non è, quindi, pericoloso come se potesse leggerli, ma è un rischio pericolosissimo per la privacy.

  • Nel forum di Mozilla Italia hanno comunicato che la nuova release FF 2.0.0.2 sarà disponibile tra qualche giorno, con esattezza dal 21 Febbraio, con la vulnerabilità script risolta.
    Grazie, Andrea, per la spiegazione.
    Ciao

  • @ gialloporpora.
    Sto facendo le 'prove generali' per il dopo FF-2.0.0.2 e ho disinstallato (su linux per ora) l'add-on NoScript di Maone. Sono poi andato su pref.js e trovato le seguenti due righe.
    ———–
    user_pref("capability.policy.maonoscript.javascript.enabled", "allAccess");
    user_pref("capability.policy.maonoscript.sites", "flashgot.net google.com googlesyndication.com hotmail.com informaction.com live.com maone.net mozilla.com mozilla.org mozillazine.org msn.com noscript.net passport.com passport.net passportimages.com yahoo.com yimg.com about:blank about:config about:credits about:neterror about:plugins chrome: resource:");
    ————-
    Domanda: devo cambiare, come da te suggerito sopra, "allAccess" in "noAccess"? E a seguire, dopo l'installazione di FF-2.0.0.2 l'altra riga deve essere cancellata manualmente?

  • @Giuseppe,
    ti sarei grato se non postassi sul Forum di MozillaItalia link a discussione fatte sul Blog (mandami una email se vuoi maggiori dettagli su questo).

    2) per la tua richiesta, il BUG perché si manifesti ha bisogno di tre condizioni:
    1) siano attivati gli script che permettono di registrare il cooki;
    2) FF sia impostato per accettare i cookie dal dominio;
    3) sia consentito al sito di modificare la proprietà dom.location.hostname, come indicato nel commento numero due di @prometeo sul link che avevo indicato.

    Basta venga meno una di queste tre condizioni e l'attacco non può manifestarsi.

    In condizioni normali le tre operazioni sono pienamente lecite, ma, in presenza di questo BUG per non correre rischi meglio limitarle.

    La riga di codice da inserire indicata su mozillalinks blocca la modifica da parte del sito della proprietà dom.location.hostname rendendo inefficace lattacco.
    Quell'impostazione di sicurezza non è visibile da about:config quindi per rimuoverla devi editare a mano il prefs.js.

    Le preferenze relative a Noscript rimangono anche dopo la disinstallazione ma è come non ci fossero.

    Ciao

  • Confermo che con la 2.0.0.2 RC4 (la versione ufficiale credo esca la prossima settimana) il BUG è stato risolto e sempre stando ai proof of concept sembra sia stata messa una pezza anche al problema al password manager.
    Ciao

Leave a Reply