Fonctionnement de la pile

La pile est un élément crucial dans un programme qui peut être l'objet de beaucoup d'attaques. Il est important de bien comprendre son fonctionnement si on veut être capable d'en exploiter ses vulnérabilités.
Comme je l'ai expliqué dans la Segmentation de la mémoire d’un programme, lors de l'appel d'une fonction une zone de la pile est réservée appelée stack frame. Il permet de stocker tout les éléments nécessaires au bon fonctionnement de la fonction comme ses variables locales et ses arguments, et tout le nécessaire pour remettre la pile et le programme dans son état d'origine lorsque la fonction se sera terminée.

Le nom du segment (stack) lui vient de sa façon de fonctionner, il se comporte comme une pile avec un fonctionnement LIFO (Last In First Out) ou FILO (ce qui revient au même). A chaque fois qu'une fonction est appelée, un stack frame est empilé dans la pile, et à chaque fois qu'une fonction se termine, un stack frame est dépilé.

Voilà l'état de la pile dans le programme de mon précédent post juste avant le retour de la fonction g() appelée dans f().

La pile étant en réalité juste une zone mémoire, le programme a besoin de savoir où se trouve le sommet de la pile. Pour cela un registre du processeur existe et s'appelle ESP qui pointe toujours sur le sommet (paradoxalement le sommet de pile est l'adresse la plus basse de la pile). De la même façon un registre nommé EBP pointe sur le début du stack frame courant (et a donc une adresse plus haute).

Exécution d'une fonction

L'exécution d'une fonction se fait en plusieurs étapes :

• La préparation des arguments de la fonction
• L'appel de la fonction
• Prologue de la fonction qui va permettre de réserver l'espace nécessaire aux variables locales
• L'exécution de la fonction
• Le retour de la fonction et la libération du stack frame

Chaque étape va être décrite précisément sur le programme suivant et grâce à gdb muni d'un .gdbinit bien configuré (merci au blog de StalkR pour me l'avoir fait découvrir).

#include <stdio.h>
#include <stdlib.h>
 
void f(int x, int y) {
 int local1 = 1;
 char local2[] = "buffer";
 return;
}
 
int main(int argc, char **argv) {
 f(1,2);
 
 return EXIT_SUCCESS;
}

# gcc stack_frame.c -w -O0 -ggdb -std=c99 -static -D_FORTIFY_SOURCE=0 -fno-pie -Wno-format -Wno-format-security -fno-stack-protector -z norelro -z execstack -o stack_frame

Il est important de bien compiler le programme avec les mêmes options, sinon gcc met certaines protections sur la pile qui vont rendre les choses plus compliquées à comprendre, comme l'inversion ou l'ajout de certaines zones mémoires. Cela s'appelle le SSP ou Stack Smashing Protection, que j'essaierai de développer dans un autre article.

Préparation des arguments de la fonction

On commence par désassembler le programme :

time0ut# gdb -q stack_frame
Reading symbols from time0ut/stack_frame...done.
gdb$ dis main
Dump of assembler code for function main:
   0x080482c0 <+0>: push   ebp
   0x080482c1 <+1>: mov    ebp,esp
   0x080482c3 <+3>: sub    esp,0x8
   0x080482c6 <+6>: mov    DWORD PTR [esp+0x4],0x2
   0x080482ce <+14>: mov    DWORD PTR [esp],0x1
   0x080482d5 <+21>: call   0x80482a0 
   0x080482da <+26>: mov    eax,0x0
   0x080482df <+31>: leave  
   0x080482e0 <+32>: ret 
End of assembler dump.1
gdb$ dis f
Dump of assembler code for function f:
   0x080482a0 <+0>: push   ebp
   0x080482a1 <+1>: mov    ebp,esp
   0x080482a3 <+3>: sub    esp,0x10
   0x080482a6 <+6>: mov    DWORD PTR [ebp-0x4],0x1
   0x080482ad <+13>: mov    DWORD PTR [ebp-0xb],0x66667562
   0x080482b4 <+20>: mov    WORD PTR [ebp-0x7],0x7265
   0x080482ba <+26>: mov    BYTE PTR [ebp-0x5],0x0
   0x080482be <+30>: leave  
   0x080482bf <+31>: ret
End of assembler dump.
gdb$ b *0x080482d5
Breakpoint 1 at 0x080482d5: file stack_frame.c, line 11.
gdb$ r
Breakpoint 1, 0x080482d5 in main (argc=0x1, argv=0xbffff324) at stack_frame.c:11
11  f(1,2);
gdb$ x/2xw $esp
0xbffff280: 0x00000001  0x00000002

Les deux commandes spécifiées en gras permettent de mettre les arguments de la fonction sur la pile. L'argument 2 est mis en premier puis l'argument 1. Lors de l'appel d'une fonction les arguments sont donc mis dans l'ordre inverse.
La commande gdb x/2xw $esp permet d'afficher 2 mots (2*4 octets) en hexadécimal à l'adresse pointée par ESP qui a pour valeur 0xbffff280. On affiche donc 2 éléments de la pile qui sont les arguments 1 et 2.

L'état de la pile avant l'appel de la fonction (c'est à dire avant l'exécution de call 0x80482a0) est donc comme suit :

Appel de la fonction

Une fois les arguments de la fonction empilés, l'appel peut se faire via la commande call, qui se fait à l'adresse 0x080482d5. La commande call a deux objectifs :

• Sauvegarder dans la pile l'adresse de l'instruction qui suit le call ce qui permettra de reprendre où on en est à la fin de l'exécution de la fonction. Cela se fera grâce au registre EIP qui pointe toujours sur la prochaine instruction à exécuter.
• Sauter dans le code (segment text) de la fonction en modifiant le registre EIP pour que celui ci pointe sur la première instruction de la fonction et dont l'adresse est passée en paramètre à call.

On vérifie tout cela avec gdb :

gdb$ print/x $eip
$1 = 0x80482d5  # EIP pointe bien pour le moment sur l'instruction call
=> 0x80482d5 
: call   0x80482a0 
   0x80482da 
: mov    eax,0x0
   0x80482df 
: leave
gdb$ stepi # On exécute le call et donc on rentre dans la fonction
gdb$ print/x $eip
$2 = 0x80482a0  # Après le call EIP pointe sur la première instruction de f
=> 0x80482a0 : push   ebp
   0x80482a1 : mov    ebp,esp
   0x80482a3 : sub    esp,0x10
gdb$ x/3xw $esp
0xbffff27c: 0x080482da 0x00000001 0x00000002 # Le sommet de pile a bougé et on a maintenant l'adresse de la prochaine instruction a exécuter après f

On peut remarquer que la prochaine instruction à exécuter après la fonction (0x080482da) se trouve 5 octets plus haut que l'instruction du call. C'est toujours le cas, car la taille de l'instruction call est de 5 octets.

Après le call, la tête de notre pile est donc la suivante :

Prologue de la fonction

Le prologue de la fonction va permettre de réserver l'espace nécessaire pour stocker les variables locales. Il est constitué de 3 instructions :

• push ebp
Cette instruction va permettre de sauvegarder le registre EBP qui pointe encore sur le début du stack frame de la fonction appelante. Cela permettra de le restaurer après la fin de la fonction courante.

• mov ebp,esp
Cette instruction permet de dire au programme que le début du stack frame commence ici. Heureusement on vient de sauvegarder EBP, donc on a pas perdu sa valeur.

• sub esp,0x10
Cette instruction permet de réserver l'espace nécessaire aux variables locales de la fonction. Dans notre cas, on réserve 0x10 soit 16 octets. En réalité nous n'aurions besoin de réserver que 12 octets (local1 fait 4 octets et local2 7 octets, mais comme on fonctionne par mot de 4 octets, cela fait 12). Cependant le compilateur gcc alloue un supplément de mémoire. Il faut noter que comme la pile grandit vers les adresses basses, la réservation d'espace se fait via une soustraction et non une addition.

On vérifie tout cela avec gdb:

gdb$ print/x $ebp
$3 = 0xbffff288
gdb$ stepi # Exécution de push ebp
gdb$ x/4xw $esp
0xbffff278: 0xbffff288 0x080482da x00000001 0x00000002 # Le sommet de pile a bougé et on a maintenant l'adresse de EBP
gdb$ stepi # Exécution de mov ebp,esp
gdb$ x/4xw $ebp
0xbffff278: 0xbffff288 0x080482da x00000001 0x00000002 # EBP et ESP pointent sur la même zone mémoire
gdb$ stepi # Exécution de sub esp,0x10
gdb$ print/d $ebp-$esp
$4 = 16 # On vient de réserver 16 octets
gdb$ stepi # On passe toutes les inialisations des variables locales
gdb$ stepi
gdb$ stepi
=> 0x80482be : leave  
   0x80482bf : ret    
   0x80482c0 
: push   ebp
gdb$ x/8xw $esp
0xbffff268: 0x080cd0ac 0x66756200 0x00726566 0x00000001
0xbffff278: 0xbffff288 0x080482da 0x00000001 0x00000002

La valeur 0x080cd0ac sur le sommet de pile est une valeur ajoutée par gcc. Elle ne nous intéresse pas. Les valeurs 0x66756200 et 0x00726566 sont en réalité la variable locale appelée local2 dans f() : 0x66 (f) 0x75 (u) 0x62 (b) 0x72 (r) 0x65 (e) 0x66 (f). La valeur suivante est la variable local1.

gdb$ x/12b 
0xbffff26c: 0x00 0x62 0x75 0x66 0x66 0x65 0x72 0x00
0xbffff274: 0x01 0x00 0x00 0x00

Comme on peut le voir ici, et plus particulièrement à l'adresse 0xbffff274, les octets sont stockés en mémoire dans le sens inverse, c'est à dire que les octets de poids faible sont stockées en premier. Ceci est dû au fait je tourne sur une architecture x86 qui est en little endian.

Voilà ce que donne la mémoire si on précise l'ordre des octets :

Si la variable local2 commence à l'adresse 0xbffff26d et non à l'adresse 0xbffff26c c'est car le compilateur connaît exactement la taille du buffer qui fait 7 octets (taille de la chaine "buffer" + \0). L'octet 0x00 de l'adresse 0xbffff26c, est juste du padding.

Retour de la fonction et libération du stack frame

Le retour d'une fonction se fait par les instructions leave puis ret.

• Instruction leave
L'instruction leave a pour objectif de supprimer le stack frame, c'est à dire de rétablir les registres ESP et EBP à leur valeur avant le call. Elle est équivalente aux deux commandes suivantes : 
• mob esp,ebp qui aurait pour objectif de remettre ESP à la même valeur que EBP (c'est à dire pointant sur la zone mémoire contenant l'ancienne valeur de EBP).
• pop ebp qui aurait pour objectif de remettre l'ancienne valeur de EBP dans EBP, et du coup de décrémenter ESP de 4 octets pour qu'il pointe sur l'instruction suivant le call

Bien entendu le leave se fait en une seule instruction, du coup l'état intermédiaire présenté dans la première figure n'existe pas réellement.
• Instruction ret
L'instruction ret a pour objectif de remettre le registre EIP à la valeur qui pointe sur l'instruction après le call. Suite au leave, ESP pointe sur une zone mémoire contenant l'adresse de l'instruction suivant le call. Elle est donc équivalent à l'instruction pop eip.

Même si les variables locales sont toujours présentes dans la pile, elles sont considérées comme de l'espace vide. La pile se retrouve donc dans l'état qui était le sien avant le call. La fonction appelante (ici main) a en charge de nettoyer les paramètres.

Cet article permet d'expliquer précisément le fonctionnement de la pile. Il peut y avoir certaines différences en fonction de l'architecture sur laquelle tourne le programme, du compilateur ou même des options de compilation. Cependant l'idée principale reste la même. La compréhension de cet article sera nécessaire pour la compréhension de quelques uns de mes prochains articles.