 Les buffers overflow
Qu'est-ce que c'est ?
Un buffer overflow est une attaque très efficace et assez compliquée à réaliser. Elle vise à exploiter une faille, une faiblesse dans une application ( type browser, logiciel de mail, etc... ) pour executer un code arbitraire qui compromettra la cible ( acquisition des droits administrateur, etc... ).
En bref
Le fonctionnement gébéral d'un buffer overflow est de faire crasher un programme en écrivant dans un buffer plus de données qu'il ne peut en contenir ( un buffer est un zone mémoire temporaire utilisée par une application ), dans le but d'écraser des parties du code de l'application et d'injecter des données utiles pour exploiter le crash de l'application.
Cela permet donc en résumé d'exécuter du code arbitraire sur la machine où tourne l'application vulnérable.
L'intérêt de ce type d'attaque est qu'il ne nécessite pas -le plus souvent- d'accès au système, ou dans le cas contraire, un accès restreint suffit. Il s'agit donc d'une attaque redoutable. D'un autre côté, il reste difficile à mettre en oeuvre car il requiert des connaissances avancées en programmation; de plus, bien que les nouvelles failles soient largement publiées sur le web, les codes ne sont pas ou peu portables. Une attaque par buffer overflow signifie en général que l'on a affaire à des attaquants doués plutôt qu'à des "script kiddies".
Technique
Le problème réside dans le fait que l'application crashe plutôt que de gérer l'accès illégal à la mémoire qui a été fait. Elle essaye en fait d'accéder ( lire, exécuter ) à des données qui ne lui appartiennent pas puisque le buffer overflow a décalé la portion de mémoire utile à l'application, ce qui a pour effet ( très rapidement ) de la faire planter.
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 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 est le pointeur du sommet de la pile.
- EBP est le pointeur de la base de la pile.
- EIP est le pointeur de la prochaine instruction à exécuter. Il pointe donc toujours une exécution en avance.
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'éffectue 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édement : 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... Historique Les buffer overflows (débordements de tampon) Windows basés sur le tas (heap), peuvent être classés en deux catégories. 1) la première couvre les débordements pour les plateformes Windows 2000, Windows Xp et Windows SP1. Le code de gestion du tas pour ces systèmes, localisé dans ntdll.dll, n'effectue aucune vérification sur les chunks du tas. Quand un débordement survient, le prochain chunk adjacent peut être sur-écrit, et si de bonnes valeurs sont soumises, une opération sur le tas (alloc, free...) peut résulter en une sur-écriture de 4 octets arbitraire en mémoire. De nouvelles techniques ont vu le jour récemment, mais le pricnipe reste le même : sur-écrire une portion spécifique de la mémoire avec des valeurs spécifiques pour obtenir le contrôle et éxecuter un payload plus tard. 2) La seconde catégorie inclue Windows SP2 et Windows 2003. Microsoft a modifié les structures du tas et les fonctions de manipulation du tas; deux vérifications sur les chunks ont été ajoutées. La première vérification consiste à vérifier l'intégrité d'un cookie de sécurité dans l'entête du chunk, pour s'assurer qu'aucun débordement n'est survenu quand ce mêm chunk est alloué. La seconde vérification extrêmement efficace, vérifie les pointeurs des liens suivants et précédents d'un chunk libre étant délié, et ce pour n'importe qu'elle rasion (allocation coalescence). La même vérification est réalisée pour les blocs alloués virtuellement. D'autres protections ont été introduites, comme le PEB aléatoire, et l'encodage des pointeurs de fonctions fixes et connus utilisés globalement par le processus. Une des méthodes consiste à exploiter les vérifications inexistantes sur la liste lookaside.
Le premier dword d'une entrèe lookaside est le début d'une liste simplement chainée de chunks, marquées comme occupés, mais prêts à être alloués. Lors d'une allocation, le premier bloc d'une liste lookaside correspodante peut être retourné : il est simplement retiré de la liste en remplaçant le pointeur de lien suivant (Flink) dans l'entrée lookaside par le pointeur Flink du nouveau bloc alloué. Une nouvelle manière de contourner les protections du tas Le tas par défaut d'un processus, comme les autres tas crées par le système, est utilisé par beaucoup d'APIs pour enregistrer des informations concernant le processus et son environnement. Quand une DLL est chargée, sa fonction principale est éxécutée (DLLMain par exemple) et souvent, les données peuvent être stockées sur le tas du processus. Que se passe-t-il si ces parties de données sont sur-écrites ? Prenons l'exemple d'un programme basique comme le Bloc Notes de Windows (notepad). Nous pouvons remarquer que même ce programme requière un grand nombre de librairies dynamiques pour s'éxécuter. Si nous examinons le tas par défaut, avant que le trhead principal commence de s'éxécuter, nous verrons qu'un bon nombre de "heap chunks" ont étés alloués par ces DLLs. Beaucoup de ces chunks ont une taille de 40 octets (incluant 8 octets pour l'entête). La technique fonctionne car:
- Aucune vérification n'est effectué sur ces pointeurs précédent et suivant spécifiques,
- Les sections critiques sont détruites pendant la terminaison du processus; cela assure la réalisation de la sur-écriture,
- Les structures de liaison peuvent facilement être trouvées dans le tas par défaut; si nous contrôlons la taille du chunk dans lequel nous sur-écrivons, nous pouvons l'ajuster de manière à ce qu'une structure de liaison réside quelques octest après. Conclusions Cette technique a été utilisée pour exploiter avec succés un heap overflow non corrigé localisé dans un utilitaire standard de Windows XP SP2. L'exploitation de heap overflow sur les derniers systèmes Windows est donc possibles, mais les problèmes sont d'améliorer leur portabilité et leur fiabilité. Pour éviter d'avoir des buffers ou heap overflow, et ainsi que les heckers puisse exploiter votre station de travail, les éditeurs mettent de plus en plus en place des solutions détectantet analysant ces comportements. Il est important de mettre des protections de ce types sur les machines principales de votre entreprises. Elles portent comme nom Hive ( Bitdefender), TruPrevent ( Pandasoftware), Defense Proactive (Kaspersky)... |
SECURITE 
Nous avons changés de numéros de téléphone.
...
RECHERCHER UNE NEWS