Buffer Overflow : Comprendre et Prévenir les Dépassements de Tampon

Introduction

Dans le monde du développement logiciel, le buffer overflow – ou dépassement de tampon – reste l’une des vulnérabilités les plus redoutées par les équipes de sécurité. Malgré l’apparente simplicité du concept, ses conséquences peuvent être dramatiques : plantage d’applications, exécution de code malveillant, prise de contrôle totale d’un serveur. Cet article propose un tour d’horizon complet du dépassement de tampon, en partant de la définition fondamentale, en passant par des exemples de code courants, jusqu’aux bonnes pratiques et alternatives sécurisées qui permettent de protéger vos projets contre ce type d’erreur.

Qu’est‑ce qu’un buffer overflow?

Un buffer (ou tampon) est une zone de mémoire contiguë utilisée pour stocker temporairement des données, souvent lors d’un transfert entre deux emplacements (lecture d’un fichier, réception de données réseau, saisie utilisateur, etc.). Un dépassement de tampon survient lorsque le programme écrit plus de données que la capacité du buffer. Les octets excédentaires débordent alors sur les emplacements mémoire adjacents, corrompant des variables, des pointeurs ou même les adresses de retour stockées sur la pile.

Cette corruption peut toucher des registres clés comme l’Instruction Pointer (IP) ou le Base Pointer (BP). Lorsque le processeur tente d’exécuter l’instruction pointée par un registre altéré, il génère généralement une exception de segmentation (segmentation fault) qui entraîne l’arrêt brutal de l’application. Dans le meilleur des cas, le programme se contente de planter ; dans le pire, un attaquant exploite ce débordement pour injecter du code et prendre le contrôle du processus.

Les dépassements de tampon sont le plus souvent le résultat d’une mauvaise gestion de la mémoire au niveau du code source: aucune vérification de la taille des données entrantes, utilisation de fonctions de bibliothèque réputées dangereuses, ou absence de mécanismes de protection au niveau du système d’exploitation. Les cibles typiques comprennent les serveurs Web, les services réseau, les bibliothèques partagées et, plus généralement, toute application qui traite des entrées non fiables.

Analyse détaillée d’exemples classiques

Exemple 1: un petit programme C vulnérable

#include <stdio.h>
int main(int argc, char **argv)
{
char buf[8]; // buffer de huit octets
gets(buf); // lecture sans contrôle (fonction dangereuse)
printf("%s\n", buf); // affichage du contenu
return 0;
}

Ce code lit une chaîne depuis l’entrée standard grâce à la fonction gets(). Cette fonction ne connaît aucune limite; elle continue d’écrire tant qu’elle lit des caractères, même si le buffer ne peut contenir que huit octets.

1234
1234

Lorsque l’on saisit une chaîne courte, par exemple 1234, le programme fonctionne correctement: les quatre caractères sont stockés dans buf, puis affichés. En revanche, si l’on saisit une chaîne plus longue, comme 123456789012, les quatre caractères supplémentaires débordent de buf et écrasent la zone mémoire suivante, qui contient notamment la valeur de retour de la fonction main. Le résultat est une segmentation fault qui interrompt l’exécution.

123456789012
123456789012
Segmentation fault

Ce comportement illustre deux points cruciaux:

1. Le débordement n’est pas limité à la zone du buffer – il affecte toute la pile, y compris les adresses de retour et les variables locales.
2. printf affiche les caractères débordés parce que la chaîne de caractères n’est plus terminée par un caractère nul ('\0') à l’endroit prévu; la fonction continue à lire la mémoire adjacente jusqu’à rencontrer ce marqueur.

Exemple 2: un dépassement qui perturbe le flux d’exécution

#include <stdio.h>  
#include <string.h>  
  
void doit(void) {  
    char buf[8];  
    gets(buf);  
    printf("%s\n", buf);  
}  
  
int main(void) {  
    printf("So... The End...\n");  
    doit();  
    printf("or... maybe not?\n");  
    return 0;  
}  

So... The End...
TEST
TEST
or... maybe not?

Ici, la fonction doit() encapsule le même buffer de huit octets. Le programme principal affiche un message, appelle doit(), puis tente d’afficher un second message. Avec une entrée correcte (TEST), tout se déroule comme prévu: le texte avant et après l’appel à doit() s’affiche.

So... The End...
TEST123456789
TEST123456789
Segmentation fault

Lorsque l’on saisit une chaîne plus longue (TEST123456789), le débordement affecte la zone de la pile qui stocke l’adresse de retour de doit(). Ainsi, au retour, le processeur saute vers une adresse invalide, provoquant à nouveau une segmentation fault. Le message “or… maybe not?” n’est jamais atteint, montrant comment un simple dépassement peut interrompre le flux logique d’une application.

Ces deux exemples montrent que le problème ne vient pas du langage en soi, mais de l’utilisation de fonctions qui ne contrôlent pas la taille des entrées.