Une vulnérabilité dans sudo expose les systèmes Linux à une élévation de privilèges totale. Face aux premiers cas d’exploitation observés, l’agence américaine CISA tire officiellement la sonnette d’alarme.
Sudo, l’outil qui permet depuis des décennies de lancer des commandes avec les privilèges root sur Linux, fait l'objet d’une vulnérabilité critique, désormais confirmée comme exploitée dans des attaques réelles d’après la CISA. Découverte par le chercheur Rich Mirch et rendue publique fin juin, elle a rapidement donné lieu à une preuve de concept puis à des codes d’exploitation plus aboutis, aujourd’hui aux mains des attaquants. Le correctif est déjà disponible et les systèmes vulnérables devraient être mis à jour sans attendre.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Une élévation de privilèges critique déjà utilisée par des attaquants
La vulnérabilité, suivie sous l’identifiant CVE-2025-32463, affecte les versions 1.9.14 à 1.9.17 de sudo, l’outil qui permet à un utilisateur d’exécuter des commandes avec les privilèges d’un autre compte, le plus souvent root. Son fonctionnement repose sur un fichier de configuration, sudoers, qui définit quels utilisateurs peuvent recourir à sudo, avec quels privilèges et pour quelles commandes. Un compte qui n’y figure pas ne devrait donc jamais pouvoir obtenir de droits admin.
Ce principe a été fragilisé par une modification introduite en juin 2023 avec la version 1.9.14. Jusqu’alors, sudo vérifiait d’abord les droits de l’utilisateur dans sudoers, puis préparait l’environnement d’exécution demandé. Depuis ce changement, l’ordre s’est inversé : sudo configure d’abord l’environnement, puis, seulement après, contrôle les autorisations.
Ce nouveau mode de fonctionnement a ainsi introduit la possibilité d’abuser de l’option -R (ou --chroot), qui sert à exécuter une commande dans un environnement dont la racine du système de fichiers est redéfinie par l’utilisateur. En principe, elle permet d’isoler l’exécution d’un programme dans un répertoire précis, mais elle n’est censée être accessible qu’aux comptes autorisés par le fichier sudoers.
Or, avec l’inversion de l’ordre des vérifications, même un utilisateur sans aucun droit sudo peut donc faire préparer un environnement qu’il contrôle. Il lui suffit alors d’y placer un fichier /etc/nsswitch.conf, qui indique normalement au système comment retrouver les informations sur les utilisateurs et les groupes, mais peut aussi demander le chargement de bibliothèques partagées selon les instructions qu’il contient. En le modifiant, l’attaquant peut ainsi forcer le chargement de sa propre bibliothèque malveillante, puis exécuter du code arbitraire avec les privilèges root.
Comment se protéger et limiter les risques
Même si la faille nécessite un accès local, le risque est élevé. Un attaquant qui compromet un compte standard (par exemple via un service exposé ou un mot de passe faible) peut ensuite obtenir un contrôle total de la machine. Les environnements multi-utilisateurs, les serveurs partagés ou tout système accessible à plusieurs comptes non privilégiés sont particulièrement concernés.
Pour se protéger, la mesure la plus directe consiste à passer à sudo 1.9.17p1 ou à une version plus récente. C’est à partir de ce correctif que le comportement problématique a été supprimé et que l’option --chroot a officiellement été dépréciée. La plupart des distributions Linux l’ayant déjà intégré dans leurs dépôts, actualiser les paquets du système devrait suffire pour corriger la faille.
Pour les environnements où la mise à jour immédiate n’est pas possible, il est conseillé d’inspecter la configuration existante. Les administrateurs et administratrices peuvent vérifier si des règles exploitent encore l’option --chroot ou la directive runchroot dans les fichiers sudoers (y compris ceux situés dans /etc/sudoers.d ou stockés dans un annuaire LDAP).
Enfin, de manière générale, pour réduire la surface d’attaque, mieux vaut limiter le nombre de comptes disposant d’un accès shell et surveiller les journaux afin de repérer toute utilisation suspecte de sudo. Vous pouvez aussi envisager de désactiver complètement l’usage de l’option --chroot lorsqu’elle n’est pas indispensable, d’autant que son maintien est amené à disparaître dans les prochaines versions de sudo.
Sources : CISA, Richard Mirch, sudo
