Auteurs : Olivier STHIOUL et Ludovic MILLON

Introduction

L'attaque par Buffer Overflow (dépassement de tampon mémoire) est l'exploitation d'une faille de mémoire, durant laquelle l'écriture en mémoire du buffer dépasse son espace mémoire alloué. Le processus subit alors une modification des informations nécessaires au fonctionnement du programme. Ces attaques ciblent le plus souvent des sites web, des applications de bureau ou même le système d'exploitation du serveur qui héberge le site web.

La plupart des failles se trouvent (pour un site web), dans les modules installés sur le serveur comme mod_php ou mod_ssl. Il y a par exemple la possibilité de désactiver des fonctions php dans son fichier de configuration. Par défaut, certaines de ces fonctions sont désactivées car elles ont été reconnues comme comportant des failles de sécurités.

L'attaque a pour objectif de faire crasher le programme ou l'application et d'exploiter une faille, en remplaçant, par exemple, le code source du programme. Un de ses avantages est qu'il n'y a pas besoin d'avoir accès à la machine victime.

Ce type d'attaque nécessite des compétences pointilleuses en informatique et particulièrement en sécurité informatique, et en code assembleur.

Principe de l'attaque

Comme l'attaque Buffer Overflow se base principalement sur la mémoire, il est important d'avoir quelques notions sur la pile d'exécution et sur le code assembleur.

Rappels sur la pile d'exécution

On peut représenter un processus ainsi que sa pile d'exécution par les schémas suivants :

Les zones text et data contiennent respectivement le code source du programme et ses données statiques. Le tas est la zone dans laquelle sont stockées toutes les données allouées dynamiquement.

Dans ce schéma, les adresses sont classées de haut en bas mais les valeurs sont empilées en haut car il s’agit d’une pile. Les différentes zones (en partant du bas du schéma) sont détaillées ci-dessous :

les paramètres supplémentaires sont ceux passés à la fonction en cours d’exécution : on parle de paramètres « supplémentaires » car les 6 premiers paramètres seront passés dans des registres ;
l’adresse de retour est l’adresse de l’instruction suivant l’appel de la fonction en cours d’exécution dans la fonction appelante (i.e. c’est là qu’on revient quand on exécute return à la fin de la

fonction) ;

le %rbp « précédent » est la sauvegarde du pointeur de base de la fonction appelante (on détaillera son rôle plus bas) ;
les variables locales de la fonction en cours d’exécution sont localisées dans son cadre de pile, à des adresses fixes par rapport à %rbp ;
on peut éventuellement utiliser de la place dans le cadre de pile pour sauvegarder des registres ou des valeurs temporaires si besoin ;
les contextes d’exécution s’empilent les uns au dessus des autres lors des appels de fonctions, donc on retrouve la même structure en haut du schéma si la fonction appelée appelle elle-même une autre fonction.

La zone de la pile d'exécution est utilisée par les fonctions (stockage des variables locales et passage des paramètres). Elle se comporte comme une pile, c'est-à-dire dernier entré, premier sorti. Les variables et les paramètres d’une fonction sont empilés avant le début de la fonction et dépilés à la fin de la fonction.

Une fonction est une suite d'instructions. Les instructions d'une fonction peuvent être exécutées (en informatique, on dit que la fonction est appelée) à partir de n'importe quel endroit d'un programme. À la fin de l'exécution des instructions de la fonction, l'exécution doit se continuer à l'instruction du programme qui suit l'instruction qui a appelé la fonction.

Technique

D'un point de vue plus technique, la pile (stack en anglais) est une partie de la mémoire utilisée par l'application pour stocker ses variables locales. Nous allons utiliser l'exemple d'une architecture Intel (32 bits). Lors d'un appel à une sous-routine, le programme empile (push) le pointeur d'instruction (EIP) sur la pile (stack) et saute au code de la sous-routine pour l'exécuter. Après l'exécution, le programme dépile (pop) le pointer d'instruction et retourne juste après l'endroit où a été appelée la sous-routine, grâce à la valeur d'EIP. En effet, comme EIP pointe toujours vers l'instruction suivante, lors de l'appel de la sous-routine il pointait déjà vers l'instruction suivante, autrement dit l'instruction à exécuter après la sous-routine (= adresse de retour).

D'autre part, lors de l'appel de la sous-routine, celle-ci va dans la majorité des cas créer sa propre pile dans la pile (pour éviter de gérer des adresses compliquées). Pour cela elle va empiler la valeur de la base de la pile (EBP) et affecter la valeur du pointeur de pile (ESP) à celle de la base (EBP).

ESP : pointeur du sommet de la pile.
EBP : (Extended Base Pointer) pointeur de la base de la pile
ESP : (Extended Stack Pointer) pointeur du sommet de la pile

En résumé, on sauvegarde la valeur originale de la base et on décale le tout ensuite. Lors du retour de la sous-routine, on dépile EBP et réaffecte sa valeur originale pour restaurer la pile initiale.

Voici pour le déroulement "normal" des opérations. Un point intéressant à citer est le fait que dans notre architecture, les zones mémoires allouées dans la stack se remplissent dans le sens croissant des adresses (de 0..0H à F..FH) ce qui semble logique. Par contre, l'empilement sur la stack s'effectue dans le sens décroissant! C'est-à-dire que l'ESB originale est l'adresse la plus grande et que le sommet est 0..0H. De là naît la possibilité d'écraser des données vitales et d'avoir un buffer overflow. En effet, si notre buffer se trouve dans la pile d'une sous-routine et si nous le remplissons jusqu'à déborder sa taille allouée, nous allons écrire par-dessus les données qui se trouvent à la fin du buffer, c'est-à-dire les adresses qui ont été empilées précédemment : EBP, EIP... Une fois la routine terminée, le programme va dépiler EIP et sauter à cette adresse pour poursuivre son exécution. Le but est donc d'écraser EIP avec une adresse différente que nous pourrons utiliser pour accéder à une partie de code qui nous appartient. (par exemple le contenu du buffer) Un problème à ce stade est de connaitre l'adresse exacte de la stack (surtout sous Windows) pour pouvoir sauter dedans. On utilise généralement des astuces propres à chaque système (librairies, etc..) qui vont permettre -indirectement- d'atteindre notre stack et d'exécuter notre code. Cela nécessite un débogage intensif qui n'est pas à la portée de tout le monde...

Exemple d'attaque

Le code ci-dessous stimule une attaque buffer overflow :

La fonction func alloue 64 octets sur la pile. Le programme prend en entrée un argument (un string) et la place dans le buffer.

Attaques références

Morris worm
SQL Slammer
Format string attack

Solutions pour éviter l'attaque

plusieurs solutions s'offrent au développeurs:

utiliser des langages haut-niveau qui intègre une gestion complète de la mémoire. Ex: Java, Cyclone...
utiliser des librairies et des fonctions sécurisés (fonction strncpy()..., librairie Libsafe) et éviter scanf / strcpy / gets
tester son code avec des logiciels spécialisé comme Qaudit ou Flawfinder
Appliquer rapidement les correctifs
CerberHost (https://www.youtube.com/watch?v=q1HODJaMY5M)