Attaques par lien symbolique : quand les opérations sur les fichiers trahissent votre confiance

Les liens symboliques sont l’une des fonctionnalités les plus puissantes des systèmes d’exploitation modernes, permettant une gestion flexible des fichiers et une architecture système élégante. Cependant, cette même flexibilité crée une surface d’attaque dangereuse qui continue de poser problème aux développeurs et aux équipes de sécurité dans le monde entier. Des escapes de conteneurs dans Docker et Kubernetes à l’escalade de privilèges sur Windows et Linux, les attaques par lien symbolique restent une menace persistante et en évolution qui nécessite une attention particulière.

Comprendre les liens symboliques et leurs implications en matière de sécurité

Un lien symbolique (symlink) est un type de fichier spécial qui sert de pointeur ou de référence vers un autre fichier ou répertoire. Contrairement aux hard links qui pointent directement vers les données sur le disque, les symlinks contiennent le chemin vers leur cible, agissant essentiellement comme des raccourcis sophistiqués. Cette indirection est précisément ce qui les rend à la fois utiles et dangereux.

Lorsqu’une application suit un symlink, elle accède généralement au fichier cible avec les permissions du processus effectuant l’opération — pas celles de l’utilisateur qui a créé le lien. Ce comportement crée des opportunités pour les attaquants de rediriger des opérations de fichiers privilégiés vers des emplacements non prévus, contournant ainsi les contrôles d’accès et manipulant des ressources système sensibles.

La préoccupation fondamentale en matière de sécurité avec les symlinks provient de la façon dont les systèmes d’exploitation résolvent les chemins de fichiers. Lorsqu’un processus privilégié ouvre un chemin contenant des symlinks, il suit ces liens de manière transparente, pouvant accéder à des fichiers que le demandeur initial ne devrait jamais toucher. Un attaquant capable de créer des symlinks dans des emplacements stratégiques peut exploiter ce comportement pour lire, écrire ou supprimer des fichiers bien au-delà de leur portée d’accès prévue.

L’anatomie des attaques par lien symbolique

Les attaques par symlink se répartissent généralement en plusieurs catégories, chacune exploitant différents aspects du comportement du système de fichiers et de la conception des applications.

Vulnérabilités de téléchargement et d’extraction de fichiers

L’une des voies d’attaque les plus répandues concerne l’extraction d’archives — une classe de vulnérabilités popularisée par la recherche “Zip Slip” divulguée en 2018, qui a affecté des milliers de projets dans plusieurs écosystèmes de programmation. L’attaque exploite des fichiers d’archives malicieusement conçus contenant des séquences de traversal de chemin ou des liens symboliques qui, lors de l’extraction, écrivent des fichiers en dehors du répertoire de destination prévu.

La variante de cette attaque utilisant des symlinks est particulièrement insidieuse. Un attaquant crée une archive contenant une entrée symlink pointant en dehors du répertoire d’extraction, suivie d’un fichier normal portant le même nom. Lors de l’extraction, le symlink est créé en premier, établissant un chemin vers un emplacement arbitraire. Lorsque le fichier suivant est extrait, l’application suit le symlink et écrit le contenu à l’emplacement contrôlé par l’attaquant.

Ce modèle de vulnérabilité continue d’apparaître dans les logiciels modernes. En avril 2025, une vulnérabilité Zip Slip a été découverte dans la bibliothèque Go populaire mholt/archiver (CVE-2025-3445), démontrant qu’en dépit des années de sensibilisation, de nouvelles instances continuent d’émerger aussi bien dans le code legacy que dans le code moderne.

Conditions de course sur les symlinks (TOCTOU)

Les conditions de course “time-of-check to time-of-use” (TOCTOU) représentent une autre catégorie majeure de vulnérabilités liées aux symlinks. Ces attaques exploitent la fenêtre entre le moment où une application vérifie les propriétés d’un fichier et celui où elle l’utilise réellement. Un attaquant pouvant remplacer un fichier légitime par un symlink durant cette fenêtre peut rediriger l’opération vers une cible non prévue.

L’exemple classique concerne des programmes privilégiés qui vérifient les permissions d’un fichier avant d’effectuer des opérations. Un utilisateur malveillant crée un lien symbolique vers un fichier auquel il n’a normalement pas accès. Lorsque le programme privilégié crée un fichier portant le même nom que le symlink, il crée en réalité (ou modifie) le fichier cible lié, pouvant insérer du contenu contrôlé par l’attaquant dans des emplacements protégés.

Ces races ont causé des impacts importants dans le monde réel. En octobre 2025, AWS a connu une perturbation majeure due à une condition de course TOCTOU dans son système de gestion DNS pour DynamoDB, entraînant une panne généralisée du service dans la région US-EAST-1. L’incident a montré comment ces conditions peuvent affecter même les infrastructures les plus sophistiquées.

Escapes de conteneurs : briser la barrière d’isolation

Les technologies de conteneurs comme Docker et Kubernetes reposent fortement sur les espaces de noms Linux et l’isolation du système de fichiers pour séparer les charges de travail. Les attaques par symlink ont maintes fois prouvé leur efficacité pour briser ces frontières, permettant aux attaquants de s’évader de l’isolation du conteneur et d’accéder au système hôte.

Vulnérabilités des vaisseaux fuyants

En janvier 2024, Snyk a annoncé la découverte de quatre vulnérabilités critiques dans Docker et Kubernetes illustrant des attaques par symlink ciblant les conteneurs. CVE-2024-21626, affectant le runtime de conteneur runC, impliquait une fuite de descripteur de fichier que les attaquants pouvaient exploiter via des symlinks pour accéder au système de fichiers hôte.

Une image de conteneur malicieuse pouvait configurer des chemins qui, par manipulation de symlinks, donnaient au processus du conteneur un accès au système de fichiers de l’hôte plutôt qu’à l’environnement isolé du conteneur. Cela donnait des privilèges de lecture, d’écriture, et potentiellement d’exécution sur les ressources de l’hôte selon les permissions du fichier leaké.

CVE-2024-23651 a démontré une condition de course de type symlink lors du processus de build de Docker. En synchronisant soigneusement les opérations de symlink lors de l’invalidation du cache, les attaquants pouvaient monter des répertoires sensibles de l’hôte dans le système de fichiers du conteneur, permettant une exfiltration de données ou une escalade de privilèges.

Les vulnérabilités runC 2025

Le paysage de la sécurité des conteneurs a été renouvelé en novembre 2025 avec la divulgation de trois nouvelles vulnérabilités de haute gravité dans runC (CVE-2025-31133, CVE-2025-52565, et CVE-2025-52881). Ces failles concernent la gestion par runC des chemins masqués, des cibles de montage, et des écritures dans procfs — toutes manipulables via des conditions de course et des abus de symlinks.

Les vulnérabilités exploitent l’utilisation par runC de /dev/null pour masquer des fichiers sensibles de l’hôte. Comme runC ne vérifiait pas que /dev/null était légitime, les attaquants pouvaient l’échanger contre un symlink lors de l’initialisation du conteneur. Cela permettait de monter arbitrairement des chemins de l’hôte dans le conteneur, permettant des écritures dans des emplacements critiques comme /proc/sys/kernel/core_pattern — un vecteur connu d’évasion de conteneur.

La technique d’évasion de journal Kubernetes illustre également ces risques. Kubernetes stocke les logs des pods dans /var/log avec des symlinks pointant vers les fichiers de logs du conteneur. Les attaquants ayant accès à un pod monté sur /var/log peuvent manipuler ces symlinks pour lire des fichiers hôte arbitraires via l’interface de logs Kubernetes, montrant comment une fonctionnalité légitime peut être instrumentalisée.

Escalade de privilèges sur les systèmes de bureau

Au-delà des conteneurs, les attaques par symlink restent une technique puissante d’escalade de privilèges sur les systèmes Windows et Linux traditionnels.

Escalade de privilèges sous Windows

Windows présente plusieurs types de symlinks que les attaquants peuvent enchaîner pour l’escalade de privilèges : junctions NTFS (redirections au niveau des répertoires), symlinks du gestionnaire d’objets, et symlinks de clés de registre. La recherche de James Forshaw et d’autres a montré comment combiner ces primitives permet des attaques puissantes contre des processus privilégiés.

CVE-2019-1161, une vulnérabilité dans Windows Defender, illustre ce schéma. Le processus MpSigStub.exe, s’exécutant avec des privilèges SYSTEM, pouvait être manipulé via des symlinks du gestionnaire d’objets pour supprimer des fichiers arbitraires. Un attaquant créait des symlinks redirigeant les opérations de fichiers de Defender vers des emplacements système protégés, réalisant une suppression arbitraire avec les privilèges les plus élevés.

Microsoft a mis en place des mitigations incluant la restriction de la création de certains types de symlinks dans des processus sandboxés et l’ajout de vérifications. Cependant, la divulgation en octobre 2025 de CVE-2025-55696 — une condition de course TOCTOU dans NtQueryInformationToken — montre que le code noyau Windows reste vulnérable à des attaques basées sur des courses pouvant mener à une escalade de privilèges.

Vulnérabilités Linux et Unix

Les systèmes Linux font face à des défis spécifiques avec les attaques par symlink dans les répertoires accessibles en écriture à tous, comme /tmp. Les vulnérabilités “Nimbuspwn” (CVE-2022-29799 et CVE-2022-29800) découvertes dans le composant systemd, notamment dans networkd-dispatcher, combinaient traversal de répertoire et races de symlink pour atteindre une escalade de privilèges root.

Les développeurs du noyau ont mis en place des protections pour les répertoires collants (comme /tmp), limitant le suivi des symlinks afin que seuls ceux appartenant au propriétaire du répertoire ou à celui de la cible du symlink puissent être suivis. Cependant, ces protections ne couvrent pas tous les scénarios, et des applications vulnérables continuent d’être découvertes.

Écosystème Apple : contournement de TCC via symlinks

En décembre 2024, Jamf Threat Labs a divulgué CVE-2024-44131, montrant comment des attaques par symlink pouvaient contourner le cadre Transparency, Consent, and Control (TCC) d’Apple sur iOS et macOS. La vulnérabilité résidait dans le composant FileProvider, permettant à des applications malicieuses d’intercepter les opérations de fichiers utilisateur et de les rediriger via des symlinks.

Lorsqu’un utilisateur déplaçait ou copiant des fichiers avec l’application Fichiers, une application malveillante en arrière-plan pouvait manipuler des symlinks pour rediriger l’opération, obtenant un accès non autorisé à des données protégées telles que les informations de santé, photos, voire accès à la caméra ou au microphone — sans déclencher de prompts utilisateur. Apple a corrigé le problème avec une validation améliorée des symlinks dans iOS 18 et macOS Sequoia 15.

Stratégies de défense et mitigation

Protéger contre les attaques par symlink nécessite une approche multicouche combinant bonnes pratiques de codage, durcissement du système et surveillance en temps réel.

Opérations de fichiers sécurisées

Les applications manipulant des opérations de fichiers, en particulier avec des privilèges élevés, devraient mettre en œuvre plusieurs mesures défensives. L’utilisation du flag O_NOFOLLOW lors de l’ouverture des fichiers empêche la résolution automatique des symlinks, forçant les applications à gérer explicitement ces liens. Avant d’effectuer des opérations sensibles, les applications devraient utiliser des fonctions comme lstat() pour vérifier si les chemins sont des symlinks et valider leurs cibles.

Pour l’extraction d’archives, les applications doivent valider que les chemins de destination restent dans les répertoires prévus après résolution des symlinks. La fonction filepath.EvalSymlinks en Go, et des outils similaires dans d’autres langages, aident à résoudre le chemin complet avant l’extraction. Les applications devraient rejeter les archives contenant des symlinks pointant en dehors du répertoire d’extraction ou, si les symlinks ne sont pas nécessaires, simplement ignorer ces entrées.

Mitigation des conditions de course

Éliminer les vulnérabilités TOCTOU nécessite des opérations atomiques combinant vérification et utilisation des ressources sans fenêtre exploitable. La création de fichiers temporaires avec O_CREAT|O_EXCL garantit une création atomique échouant si le fichier existe déjà, empêchant la substitution par symlink. La fonction mkstemp() offre une création sécurisée de fichiers temporaires évitant les noms prévisibles.

Le verrouillage de fichiers avec des API comme LockFileEx sous Windows aide à prévenir la manipulation durant des opérations critiques, bien que cela ne protège pas contre tous les scénarios d’attaque. Lorsqu’il est possible, l’utilisation de descripteurs de fichiers plutôt que de chemins pour les opérations suivantes assure que l’application continue de travailler avec la ressource initialement ouverte, indépendamment des changements de chemin.

Protections au niveau du système

Les systèmes d’exploitation offrent diverses protections contre les symlinks que les administrateurs devraient activer. La configuration fs.protected_symlinks de Linux limite le suivi des symlinks dans les répertoires collants. Windows Defender Credential Guard et la liste blanche des applications peuvent empêcher l’exécution de code non fiable dans des contextes où les attaques par symlink seraient efficaces.

Dans les environnements de conteneurs, l’activation des espaces de noms utilisateur sans mappage de l’utilisateur root de l’hôte empêche les utilisateurs en espace de noms d’accéder aux fichiers pertinents de l’hôte en raison des permissions Unix DAC. Les conteneurs sans root réduisent considérablement les dégâts potentiels des vulnérabilités d’évasion de conteneur en éliminant les privilèges root. L’application des normes de sécurité des pods, l’utilisation de profils seccomp, et la mise en œuvre de politiques AppArmor ou SELinux minimisent la surface d’attaque syscall et système de fichiers accessible aux charges de travail conteneurisées.

Surveillance et détection

Les équipes de sécurité devraient surveiller les modèles suspects de création de symlinks, en particulier dans les répertoires sensibles ou depuis des processus non privilégiés ciblant des emplacements privilégiés. Les solutions EDR peuvent signaler des opérations rapides de création de symlinks, des activités de montage inhabituelles, et des écritures inattendues dans /proc ou d’autres emplacements sensibles.

Les outils de sécurité en temps réel comme Falco peuvent détecter les tentatives d’évasion de conteneurs en surveillant la création de symlinks pointant vers des répertoires sensibles de l’hôte lors de l’initialisation du conteneur. La corrélation de ces événements avec le comportement des processus aide à distinguer les opérations légitimes des tentatives d’exploitation.

Conclusion

Les attaques par symlink occupent une position unique dans le paysage de la sécurité — elles exploitent des fonctionnalités fondamentales du système d’exploitation plutôt que des bugs d’implémentation, ce qui les rend intrinsèquement difficiles à éliminer. La série continue de CVEs affectant tout, des runtimes de conteneurs aux systèmes mobiles, montre que même les équipes de développement les plus sophistiquées ont du mal à gérer la sécurité des symlinks.

Pour les organisations, la voie à suivre consiste à reconnaître les symlinks comme une menace persistante nécessitant une attention continue. Cela implique de mettre en œuvre des pratiques de codage sécurisé dans les applications personnalisées, de maintenir à jour les runtimes de conteneurs et les composants système, d’activer les protections au niveau du système d’exploitation disponibles, et de maintenir une visibilité sur les opérations du système de fichiers pouvant indiquer une tentative d’exploitation.

Alors que les architectures cloud-native se multiplient et que les conteneurs deviennent le modèle de déploiement par défaut, la surface d’attaque pour les exploits basés sur les symlinks ne fait qu’augmenter. La couche d’exécution qui fournit l’isolation des conteneurs devient un point de défaillance unique où la manipulation des symlinks peut franchir la frontière entre les charges de travail isolées et l’infrastructure sous-jacente. Comprendre ces attaques et mettre en œuvre des défenses complètes n’est plus optionnel — c’est essentiel pour maintenir l’intégrité des environnements informatiques modernes.