La pile de mitigations : quelles défenses, dans quel ordre

Ceci est le point d'orgue de l'espace Mitigations d'exploitation. Chaque tutoriel de ce site se termine en réactivant la mitigation qui le casse. Lues ensemble, ces conclusions forment un tableau unique : un exploit est une chaîne d'étapes, et le rôle du défenseur est de casser autant d'étapes que possible. Ce guide assemble ce tableau pour Linux, ARM, Windows et le noyau, et donne un ordre priorisé pour tout activer.

Chaque exploit suit les mêmes étapes

Quelle que soit la plateforme, l'exploitation par corruption mémoire suit le même chemin. Cassez un seul maillon et la chaîne échoue.

Quelle mitigation casse quelle étape

La même étape porte un nom de mitigation différent sur chaque plateforme, mais son rôle est identique.

Chaque ligne est un maillon. Les techniques qui attaquent chacune sont cataloguées dans les espaces Techniques d'exploitation, ARM64, Windows et Noyau.

Un ordre d'activation priorisé

Pour un projet C ou C++, activez dans cet ordre — le moins cher et le plus universel d'abord :

1. Hygiène à la compilation. -Wall -Wextra -Wformat=2 -Werror=format-security ; traitez les avertissements comme des erreurs. Cela seul empêche l'envoi en production de bugs de chaîne de format.
2. Les quatre classiques peu coûteux. Canari de pile (-fstack-protector-strong), NX, ASLR + PIE (-fPIE -pie), et Full RELRO (-Wl,-z,relro,-z,now). Chacun casse une étape distincte ; voir flags de durcissement de binaire.
3. FORTIFY_SOURCE. -D_FORTIFY_SOURCE=3 -O2 ajoute des vérifications de bornes aux appels libc courants et bloque %n dans les chaînes de format inscriptibles.
4. L'arête arrière en matériel. Pile fantôme CET d'Intel, ou PAC ARM (-mbranch-protection=standard active aussi le BTI). C'est la réponse la plus directe au ROP.
5. Trouvez les bugs en continu. AddressSanitizer et le fuzzing en CI. Les mitigations ne corrigent pas les bugs ; c'est ainsi qu'on les élimine.
6. Contenez ce qui reste. seccomp pour les services exposés (voir le guide ORW), le moindre privilège et la mise en bac à sable.
7. Supprimez la classe de bug. Quand c'est faisable, écrivez les nouveaux composants dans un langage sûr pour la mémoire. C'est la seule mesure qui élimine entièrement les étapes 1–2.

Vérifiez, ne présumez pas

Un flag silencieusement ignoré ne protège rien. Confirmez ce qui a réellement été livré :

• Linux/ARM : checksec --file=./bin (canari, NX, PIE, RELRO) ; readelf -n pour BTI, PAC sous ARM.
• Windows : vérifiez /guard:cf, /DYNAMICBASE, /NXCOMPAT, /CETCOMPAT sur chaque module chargé — une seule DLL non durcie est la lacune habituelle.
• Noyau : vérifiez KASLR, SMEP/SMAP (/proc/cpuinfo), KPTI et les options de durcissement CONFIG_* dans la configuration en cours d'exécution.

Points clés à retenir

• L'exploitation est une chaîne d'étapes : bug → corruption → connaissance des adresses → détournement du flux de contrôle → exécution/réutilisation de code → escalade. Casser une seule étape arrête l'exploit.
• La même étape porte un nom de mitigation différent selon la plateforme, mais le rôle est identique — utilisez le tableau de correspondance pour voir toute la grille.
• Activez par ordre de coût : hygiène à la compilation, les quatre classiques (canari/NX/PIE/RELRO), FORTIFY, l'arête arrière matérielle (CET/PAC), sanitizers+fuzzing, confinement, et enfin les langages sûrs pour la mémoire.
• Vérifiez que chaque mitigation a réellement été livrée, sur chaque module — un flag ignoré est une lacune silencieuse.

Ce point d'orgue relie tout le site : les classes de vulnérabilités, les techniques d'exploitation, ARM64, Windows et noyau, et les mitigations qui répondent à chacune.