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 : ils correspondent à tous les paramètres après le 6ème passé dans la fonction car les 6 premiers sont placés dans le registre
l’adresse de retour est l’adresse de l’instruction de la fonction en cours d'exécution (ex: return) ;
le %rbp « précédent » correspond au pointeur de base de la fonction appelante pour les assembleurs 64 bits (l'équivalent en système 32 bits est l'EBP ;
les variables locales sont celles de la fonction en cours d’exécution, stockées dans sa pile, à des adresses toujours inférieurs et immédiates au %rbp ;
des valeurs temporaires peuvent aussi être stockées ;
à chaque appels de fonctions, le même schéma est répété

La pile d'exécution correspond donc à la zone mémoire allouée pour chaque fonction du programme en cours d'exécution. Son comportement est le même que celui d'une pile : dernier entré premier sortie. 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.

Technique

Le principe est de créer une erreur (ou un crash) du programme en cours d'exécution. Pour cela, on va exploiter la mémoire du programme et en particulier la pile d’exécution. Un programme simple alloue 24 caractères dans un tableau et copie la chaîne de caractères passée en paramètre du programme dans ce tableau. La variable sera alors copiée dans la pile à partir de l'adresse de l'ESP, qui est l'adresse mémoire correspondant au sommet de la pile. Si on choisit de mettre 24 fois la lettre A dans cette variable, on pourrait représenter l'état de la pile d’exécution avec le schéma suivant :

La pile d'exécution ne semble pas avoir de dysfonctionnement, les valeurs de la variables sont stockées entre l'adresse de l'ESP et l'adresse de l'EBP. Si on souhaite maintenant passer en paramètre du programme une chaîne de taille supérieure à 24 caractères, le schéma suivant représenterait l'état de la pile d'exécution :

On remarque que toutes les adresses entre celles de l'EBP et l'ESP sont remplies, mais aussi celles de l'EBP et de l'EIP (adresse de l'instruction courante). Dans ce cas, lorsque le programme va se terminer et qu'on va passer par l'instruction correspondant à la valeur de retour du programme, l'EIP va donc pointer vers l'adresse AAAA qui, en hexadécimal, est 0x41414141. La probabilité de pouvoir accéder à cette adresse mémoire est quasi nulle, il se peut même que cette adresse ne soit pas mappée. Il est donc inévitable de se retrouver face à une erreur de segmentation.

Pour exploiter cette faille, l'idée serait de rediriger l'adresse de l'EIP vers une partie du programme que l'on souhaiterai exécuter (en général, programme injecté dans la pile d'exécution). Il serait alors possible de faire presque tout ce qu'on voudrait sur la machine victime de l'attaque, comme par exemple ouvrir un shell et s'approprier tous les droits.

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. Il est à noter que strcpy ne vérifie pas la taille du buffer lors de la copie. On va donc choisir une chaîne de caractères plus longue que celle du buffer, comme 200 octets.

Si on tente d'afficher la chaîne de caractères, elle s'affichera correctement mais il y aura une erreur de segmentation car on essaie d'écrire dans une zone mémoire non autorisée en écriture.

Attaques références

Morris worm

Le ver Morris a été écrit par Robert Tappan Morris en 1988. Sa principale caractéristique est de se propager sur une machine et de machines en machines.

Il exploitait deux vulnérabilités dans sendmail (serveur de messagerie éléctronique open source) et dans fingerd (utilitaire permettant de connaitre l'heure de connexion sur un poste à distance). La faille de fingerd est une faille de type buffer overflow. Il permettait de prendre le contrôle de la machine à distance et d'accéder à l'utilitaire réseau de la machine. Il était alors possible de se connecter à d'autres machines depuis celles infectée, et de propager le ver grâce à la faille de sendmail. Il était possible, avec sendmail, en mode debug, d'envoyer des fichiers à distance par le shell. Le shell compilait le code source des fichiers. Il était donc possible d'envoyer le code source du ver Morris sur une machine distante.

Ce ver était aussi connu pour se diviser et ne laisser aucune traces de son passage, en effaçant les fichiers qui le contenait. Il pouvait aussi bloquer la création de processus sur la machine, ce qui rendait la machine inutilisable.

SQL Slammer

SQL Slammer, tout comme le ver Morris, est un ver informatique. Il a été créé en 2003 et a provoqué des dénis de service (attaque empêchant l'utilisation d'un service informatique), qui entraînait un ralentissement du trafic internet. Le ver exploitait une faille de sécurité de Microsoft SQL Server.

Son principe est de générer des adresses IP de façon aléatoire, et d'envoyer à ces adresse IP son code source. Les machines qui recevaient le code pouvaient être infectées si elles n'avaient pas reçu le correctif de la faille Microsoft SQL Server. Ces machines, à leur tour, envoient le code source du ver à d'autres machines. Le ver se répand alors très rapidement.

Ce ver a causé des ralentissements internet importants. De nombreux routeurs sont tombés par l'infection de serveurs par le ver, ce qui avait pour conséquence des envoies massifs d'adresses du ver depuis les serveurs, et donc une saturation du trafic internet au niveau des routeurs.

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)

Les systèmes d'exploitations eux-mêmes peuvent intégré des dispositifs qui rendent ce genre d'attaque plus compliqué:

address space layout randomization (ASLR): technique de placement aléatoire des différents éléments de la mémoire virtuelle.
NX protection: technique qui consiste à ne pas donner les droits d’exécution qu'à la zone mémoire contenant les instructions du programme
Stack-Smashing Protector: ajoute une valeur aléatoire