La commande sudo est l’une des plus connues dans les univers Linux et Unix. Maintenue par le développeur Todd Miller (OpenBSD), elle permet d’accorder temporairement des droits administrateur à la commande que l’on s’apprête à lancer. Par exemple, sur les distributions de type Debian, la commande « sudo apt update » autorise APT à récupérer les dernières informations provenant des dépôts pour savoir si des paquets peuvent être mis à jour.
Aux États-Unis, la CISA (Cybersecurity and Infrastructure Security Agency) a prévenu lundi soir qu’une faille critique dans sudo était activement exploitée. Estampillée CVE-2025-32463, elle présente un score de sévérité de 9,3 sur 10 et a été découverte en juillet. Le bulletin de l’agence ne précise pas de quelle manière elle est exploitée, ni par qui.
Toutes les versions antérieures à la 1.9.17p1 sont vulnérables. L’exploitation permet à un utilisateur local d’obtenir un accès root (par escalade de privilèges), en incitant sudo à charger une bibliothèque partagée arbitraire grâce à l’utilisation d’un répertoire racine spécifié via l’option -R (–chroot). Le pirate peut alors lancer des commandes arbitraires en tant que root sur les systèmes prenant en charge /etc/nsswitch.conf.
La CISA recommande bien sûr de mettre à jour le plus rapidement possible toutes les machines. L’agence s’adresse en priorité aux administrations et entreprises américaines, mais le conseil est valable partout.
Chez les particuliers, cette faille ne devrait pas être un problème. Elle avait été signalée immédiatement par de nombreux éditeurs (Canonical, Red Hat, SUSE…) et corrigée dans la foulée. Le problème est résolu depuis presque trois mois. Comme indiqué, le message s’adresse davantage aux grosses structures qui auraient été plus lentes à réagir.
À noter que la CISA a averti dans son bulletin de quatre autres vulnérabilités exploitées : une dans Adminer, une dans Cisco IOS/IOS XE, une dans GoAnywhere MFT de Fortra et une autre dans Libraesva.
Commentaires (22)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousModifié le 30/09/2025 à 09h27
Le 30/09/2025 à 16h54
La version installée chez moi est la 1.9.13p3
Le 30/09/2025 à 20h44
Pour info tu peux checker ici :
https://security-tracker.debian.org/tracker/CVE-2025-32463
Le 30/09/2025 à 21h54
Le 01/10/2025 à 12h31
Modifié le 30/09/2025 à 10h04
Le 30/09/2025 à 11h31
Le 30/09/2025 à 15h44
Sudo ne donne aucun droits par défaut aux user. Quand à savoir si la faille s'en préoccupe, no lo sé.
Modifié le 30/09/2025 à 16h49
Le 30/09/2025 à 19h17
Le 30/09/2025 à 10h09
Je serais curieux de savoir comment fonctionne en pratique cette faille ... Locale à la machine ? Exploitation à distance ?
Le 30/09/2025 à 10h24
Le 30/09/2025 à 10h30
Le 30/09/2025 à 10h34
En résumé, sudo appelle plusieurs fois chroot() sans vérifier que l'utilisateur a le droit d'utiliser sudo en faisant un chroot (-R ou -chroot=...). C'est un problème de codage manifestement. En fait, cette possibilité dans sudo est passée en obsolète et va être supprimée car très peu utilisée en réalité.
Donc n'importe quel utilisateur local peut exploiter la faille.
Le 30/09/2025 à 13h06
Le 30/09/2025 à 13h15
Le 30/09/2025 à 15h31
Modifié le 30/09/2025 à 11h31
sudon'implique pas d'écoute sur le réseau.Le fonctionnement est assez malin et repose sur la faculté de
sudoà faire unchroot: tu fais unsudo -Rpour lui dire de faire unchroot. Normalement, quand on arrive à ce point, tout le code de sudo est chargé, donc on n'a pas trop à se préoccuper du contenu du répertoire vers lequel ont fait le chroot contrôlé par l'utilisateur. Sauf qu'en fait, tout n'est pas chargé. Il y a des options rigolotes de sudo qui causent des résolutions DNS. Or, la façon dont on fait les résolutions DNS (fichier local, résolveur, NIS, etc.) se configure dans le fichier/etc/nsswitch.conf. Le bug, c'est que si un fichier/etc/nsswitch.confest présent dans le répertoire du chroot, c'est celui-ci qui est pris en compte plutôt que celui du système, et ça ouvre pas mal de possibilités pour un utilisateur malveillant. Je n'ai pas regardé le détail de l'exploitation de la faille, mais le nsswitch marche avec un système de plugins, donc de chargement dynamique de code ; si tu prends le contrôle là-dessus, tu injectes tout le code que tu veux dans sudo et tu es le roi du monde.Le 30/09/2025 à 12h46
Du coup, je vais me faire France Travail et tous les hôpitaux de France.
A zut.. déjà fait :(
Le 30/09/2025 à 15h34
"su" est amplement suffisant, avec l'intérêt supplémentaire d'exiger le mot de passe pour l'élévation.
Le 30/09/2025 à 16h24
sucd /
quelques commandes
exiy
rm -fr .
Oh merde ! Je n'avais pas vu le "bash: exiy : commande introuvable"
Le 30/09/2025 à 21h01
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?