Rédacteur : Heurs
Date de création : 22/03/2007
Section : Sécurité > Failles applicatives
Imprimer cet article : en noir et blanc ou en couleurs
L'off by one est une faille applicative assez dur à classer. Certains la qualifient d'under-overflow ; personnellement je considère que c'est un "mini-overflow". En fait, c'est un débordement de tampon sur un seul octet. Cette contrainte fait que l'exploitation de cette vulnérabilité est plus compliquée qu'un simple buffer overflow. Cet article l'explique en détails.
Le prologue et l'épilogue sont des règles de base quand on programme en assembleur. Ils permettent d'executer une fonction sans endomager les données environnantes. Vous devez probablement les rencontrer à chaque déboggage. Le prologue se compose en deux instructions :
Généralement un "SUB ESP, 80" par exemple suit le prologue. Ca sert à allouer l'espace mémoire pour stocker les données temporaires. Maintenant l'épilogue (on en trouve 2 sortes), la première :
Et la deuxième :
Il n'y a strictement aucune différence entre les deux si ce n'est le nombre d'opcodes et le temps processeur.
On peut voir que le prologue sauvegarde la configuration de la pile (ou stack) et que l'épilogue la restaure. Cela veut dire que si un buffer overflow a lieu, il écrasera la sauvegarde d'EBP et donc le pointeur du bas de la stack sera entièrement désordoné. Jusqu'à là ce n'est pas vraiment notre problème car généralement on saute sur un shellcode.
Regardons à présent quel bug peut se produire si seule la sauvegarde d'EBP est écrasée.
Admettons un programme appelant une fonction en interne, et cette fonction est vulénarble. Un buffer overflow se produit (mais n'écrasent que la sauvegarde d'EBP)... Regardons alors ce que cela provoque :
En rouge nous voyons les registres corrompus. On peut remarquer qu'au retour de la fonction où le débordement a lieu, le registre ESP
est tout a fait correct, donc la suite du programme se déroule correctement. Arrivé à l'épilogue de la fonction principale nous plaçons EBP dans ESP. Seulement, EBP a été écrasé... nous remplacons donc ESP par la valeur corrompue. Nous savons bien que RET (l'instruction suivante) fait un POP EIP... donc cela veut dire que l'on prend l'adresse pointée par ESP pour sauter dessus. Comme ESP a été corrompu on peut donc pointer sur une autre valeur et donc sauter ou on le souhaite.
Allez, passons à la pratique ! Je suis sous Windows, car sous Linux, à cause des paddings et de l'endroit où sont stockés les arguments c'est plus galère à faire. Et comme on fait une initation, cela ne change pas le problème. Voici le code du programme vunlérable :
Dans un premier temps, nous essaierons de sauter sur la fonction exploitation(). J'ai mis en rouge la ligne où le 'bug' se produira. Dans son enssemble le programme va appeler la fonction vuln() qui copira ARGV[1] dans un buffer (sans déborder, grace à strncpy() ) puis un bit null sera placé à argv[1][1024]. C'est là que se situe la faille : pour les pointeurs, le [0] est le 1er octet, et donc le [1024] sera le 1025e octet. Au 1025e octet nous allons alors toucher un octet en dehors de notre buffer. Et cet octet tombe exactement dans EBP, pas de bol pour le programme... Le dernier octet d'EBP sera donc mis à 0, c'est comme si on faisait à EBP un "AND EBP, FFFFFF00". Lors du "MOV ESP,EBP" final nous allons alors fair remonter ESP bien plus haut que ce qu'il devrait etre (avec un peu de chance dans notre buffer) et donc le ret se produira sur une autre adresse mais toujours dans la stack (avec un peu de chance que nous aurons pu modifier).
Une petite remaque pour la compilation du programme : GCC 3.x ajoute un padding par défaut a chaque fin de chaine, il faut donc compiler le code source avec la commande suivante (afin de retirer ce padding) :
Notre prog est compilé, voyons alors ce que cela donne si on remplit le buffer :
A ce momment on a notre gestionnaire d'exception habituel qui se lance, on affiche donc le rapport d'erreurs et on voit que cela a planté à cette adresse : "Offset: 61616161". Tiens, mais c'est notre buffer ça :-)
Afin de mieux voir ce qui se passe, on va débugger avec Ollydbg. Je pose un breakpoint sur le "call strncpy" et sur le ret de la fonction main(). Grace a ces deux point d'arret nous pourrons calculer à partir de combien d'octets nous réécrirons la sauvegarde d'EIP. J'ai donc placé les breakpoints aux adresses suivantes :
Arrivé à 004012F3 nous remarquons que les arguments suivants sont passés à la fonction :
Puis nous continuons jusqu'à 004012D1. A ce momment si nous regardons où pointe ESP, nous voyons cela :
En faisent 0x0022FF04 - 0x0022FB68 nous aurons à partir de combien d'octets EIP sera réécrit, soit 924. Testons donc ceci :
Notre gestionnaire d'exeptions se relance, et là nous pouvons voir la chose suivante "Offset: 62626262". Grace à cette information nous sommes bien sûrs que "bbbb" sera l'adresse de retour.
Essayons maintenant de sauter sur exploitation(). La fonction se trouve à l'adresse 004012FE. Nous allons alors remplacer les bbbb par \xFE\x12\x40 et le bit null se mettra tout seul à la fin comme c'est une chaine. Voici le code de l'exploit permettant de réaliser cette action :
Et on execute le prog :
Nous avons vu comment rediriger le flux d'execution du programme, nous allons à présent essayer d'executer les fonctions des DLL comme lors d'un ret into libc sous Linux.
Ici, je vais aller vite. Pour ceux qui ne savent pas comment s'empile les adresses d'appel aux fonctions et pointeurs je les renvoient à l'article sur les return into libc. Je vais donc rediriger EIP vers l'appel system() qui se trouve à l'adresse 77BF8044 dans msvcrt.dll. Puis nous allons empiler l'adresse de retour de "exitprocess" situé dans kernel32.dll , cela nous permettra de quitter proprement. Et enfin, sera empilé un pointeur vers argv[0] (pour mon exploit tout du moins) qui sera la commande executé par system(). Le code source de l'exploit est le suivant :
Pour m'amuser, je n'ai lancé qu'un simple ping. Voyons le résultat :
Evidemment, on peut exploiter cette faille par shellcode... mais bon c'était plus sympa de faire le recoupement avec le ret into libc :).
Certains peuvent se dire qu'on ne trouve et ne trouvera jamais ce genre de vunlérabilité. Fausse idée, par exemple Proftpd en avait plusieurs a son actif. Certes il est plus long d'exploiter un off by one ou off by two (comme dans le cas de proftpd) qu'un buffer overflow normal. Mais étant donné que cette vulnérabilité existe je trouvais normal de la présenter.
