« Attaque par Buffer Overflow » : différence entre les versions
| Ligne 36 : | Ligne 36 : | ||
== Technique == |
== 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). |
|||
[[Fichier:EBP-ESP.PNG]] |
|||
* 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 == |
== Exemple d'attaque == |
||
Version du 25 novembre 2018 à 21:55
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
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
Sources
https://fr.wikipedia.org/wiki/D%C3%A9passement_de_tampon
https://www.securiteinfo.com/attaques/hacking/buff.shtml
http://www.student.montefiore.ulg.ac.be/~blaugraud/node2.html
https://www.nbs-system.com/blog/cerberhost-les-attaques-de-type-buffer-overflow/
https://zestedesavoir.com/articles/143/exploitez-votre-premier-stack-based-overflow/
https://web.maths.unsw.edu.au/~lafaye/CCM/attaques/buffer-overflow.htm
http://chamilo2.grenet.fr/inp/courses/ENSIMAG3MM1LDB/document/asm_fonctions.pdf
https://fr.wikibooks.org/wiki/Programmation_Assembleur/x86/Registres
https://insecure.org/stf/smashstack.html
https://www.veracode.com/security/buffer-overflow