Les compilateurs suppriment les protections de sécurité dans le binaire

Contexte et principe

Lors d’une session à Black Hat USA 2026, le chercheur en sécurité Chris Domas a montré que le code source C, même conforme aux meilleures pratiques, peut être transformé en un exécutable vulnérable. Le compilateur, en tant qu’interprète du C abstract machine, possède la liberté de réécrire le flux d’instructions tant que le comportement observable reste identique selon la spécification du langage. Cette latitude inclut la suppression d’appels de nettoyage de mémoire, la fusion de branches conditionnelles et la réorganisation de structures en fonction de la pression des registres.

Mécanismes d’optimisation qui annulent les contrôles

Des optimisations classiques comme l’élimination de code mort (dead‑code elimination) ou la propagation de constantes peuvent effacer des fonctions de nettoyage, par exemple memset destiné à écraser des clés cryptographiques. Lorsque le compilateur estime que la valeur écrasée n’est plus lue, il la retire, laissant les données en clair dans la pile. De même, le register allocation peut forcer le déplacement de variables sensibles dans des registres qui ne sont jamais écrasés avant la fin du processus, créant ainsi une fuite potentielle.

Un cas étudié montre que des tailles d’objet de 17 ou 33 octets restent sécurisées, alors que des tailles immédiatement adjacentes (par ex. 18 octets) déclenchent la génération d’un code où le nettoyage est omis. Cette sensibilité provient de l’alignement des structures et du remplissage automatique effectué par le compilateur, qui modifie la séquence d’instructions de façon non triviale.

Analyse des patterns détectés et limites

En mobilisant une IA d’analyse statique, les chercheurs ont parcouru 500 millions de lignes de code open‑source et identifié 300 patterns susceptibles d’être exploités après optimisation. Les patterns incluent l’utilisation de alloca suivi d’un memcpy sans nettoyage, ou encore des boucles dont le corps est entièrement éliminé lorsqu’une condition est évaluée à vrai à la compilation.

Le rapport précise que le simple changement de chaîne d’outils, par exemple passer de GCC à Clang, ne résout pas le problème : les deux compilateurs appliquent des passes similaires et peuvent produire le même résultat vulnérable. L’interrogation sur Rust montre que, bien que le langage impose des règles de possession, le compilateur LLVM sous‑jacent reste capable de supprimer des appels de nettoyage si les métadonnées d’ownership sont mal exprimées.

Recommandations pour les développeurs

Les auteurs conseillent d’activer les avertissements de compilation (-Wall -Wextra) et d’utiliser les sanitizers (-fsanitize=address,undefined) pour détecter les suppressions inattendues. L’analyse des builds optimisés, à l’aide d’outils comme objdump ou llvm‑objdump, permet de comparer le binaire final avec le code source et de repérer les sections disparues. Enfin, tester le binaire exactement tel qu’il sera déployé, y compris les options d’optimisation (-O2, -Os), reste la méthode la plus fiable pour garantir que les protections implémentées ne sont pas éliminées par le compilateur.