Sudo en été : vulnérabilité critique dans les versions Linux de Sudo

Avec la chaleur qui progresse, nos corps ne sont pas les seuls à transpirer… rarement. Les systèmes Linux, eux aussi, sont confrontés à une transpiration inattendue cet été : une vulnérabilité critique découverte dans sudo, la célèbre commande qui permet depuis des décennies aux utilisateurs d'effectuer des opérations en tant qu'administrateurs sans avoir à se connecter directement en tant que root. Mais cette fois, un bug dans la gestion de --chroot risque de transformer une simple commande système en une porte ouverte pour les attaquants locaux.

Un été chaud pour la sécurité Linux

Le 1er juillet 2025, un avis officiel qui décrit une vulnérabilité classée comme CVE-2025-32463, avec un score CVSS de 9.3, ce qui en fait l’un des défauts les plus graves de ces dernières années en matière de sudoLe bug affecte les versions de sudo du 1.9.14 au 1.9.17 inclus, excluant uniquement les 1.9.17p1, qui contient la correction.

Qu'est-ce que sudo ?

sudo est l'une des commandes fondamentales de l'administration système Unix et Linux. Son nom dérive de « superutilisateur faire« », signifiant « exécuter en tant que superutilisateur ». En pratique, cela permet à un utilisateur normal d'exécuter des commandes avec les privilèges root (ou ceux d'un autre utilisateur spécifié), mais sans avoir à se connecter en tant que rootCe mécanisme est fondamental pour la sécurité : il permet de contrôler, d'enregistrer et de limiter l'accès aux privilèges administratifs.

Via le fichier de configuration /etc/sudoers, vous pouvez définir avec une extrême précision quels utilisateurs peuvent exécuter quelles commandes, sur quels hôtes et avec quelles options. Dans un contexte d'entreprise ou multi-utilisateurs, sudo vous permet de suivre les activités privilégiées et de réduire les risques associés à l'utilisation du superutilisateur. Il s’agit donc d’un pilier de la gestion sécurisée des systèmes Linux, mais précisément en raison de sa puissance, lorsqu’une vulnérabilité est découverte dans sudo, les conséquences peuvent être très graves.

Le problème en bref

Le problème vient de l’utilisation de l’option --chroot (équivalent à -R) qui permet d'exécuter des commandes dans un environnement chrooté, utile par exemple pour les opérations de maintenance sur des systèmes qui ne sont normalement pas démarrés. Cependant, dans les versions concernées, sudo ne gère pas correctement la séparation entre l'environnement chroot et le système de fichiers réel. Sous certaines conditions, un utilisateur non privilégié peut :

• créer un répertoire chroot contrôlé ;
• inclure des fichiers comme /etc/nsswitch.conf manipulé;
• profiter du chargement dynamique des bibliothèques configurées dans nsswitch.conf;
• ottenere exécution de code avec des privilèges root.

Il ne s’agit pas d’une attaque à distance, mais elle est néanmoins dévastatrice, car un utilisateur local sans privilèges root suffit qui a accès à la commande sudo, même juste pour un sous-ensemble de commandes.

Comment fonctionne l'exploit (en termes généraux)

Un attaquant peut construire un faux environnement chroot avec :

1. Une copie de /bin/sh ou autre exécutable essentiel pour démarrer un shell de base dans le contexte isolé ;
2. Une version artificielle de /etc/nsswitch.conf, contenant des références à des modules personnalisés pour la résolution de noms, tels que :

   passwd: mymaliciousmodule
   group: mymaliciousmodule
   shadow: mymaliciousmodule

   Cela va forcer sudo pour charger une bibliothèque .so correspondant à libnss_mymaliciousmodule.so.2;

3. Une bibliothèque .so malveillant, écrit et compilé ad hoc, placé dans la structure simulée de /lib, /usr/lib ou similaire dans le chroot, afin qu'il puisse être détecté par le linker dynamique ;
4. Une structure cohérente minimale dans le chroot, qui permet à la commande invoquée (par exemple /bin/sh) pour démarrer et générer le moins d'erreurs possible (y compris des dispositifs factices spéciaux, /proc, tous les liens symboliques) ;
5. Enfin, exécutez la commande :

   sudo -R /tmp/fakechroot /bin/sh

À ce stade, sudo, en respectant le paramètre --chroot, changez la racine vers le chemin spécifié (/tmp/fakechroot) et exécute la commande demandée. Ce faisant, il tente de résoudre les configurations nsswitch, chargement de modules dynamiques avec des privilèges élevés. Puisque la bibliothèque .so est placé par un attaquant et contient du code arbitraire, qui est exécuté en tant que root dans le cadre du processus sudo.

L’aspect le plus critique est que cela se produit sans exploiter les vulnérabilités classiques comme un dépassement de tampon ou une corruption de mémoire : il s'agit d'un abus logique, basé sur la confiance que sudo réinvestit dans l'infrastructure chroot. Pour cette raison, l'attaque est relativement simple à réaliser pour toute personne disposant d'un accès local et même d'une autorisation partielle. sudo.

Quelles distributions sont vulnérables ?

Les distributions vulnérables sont toutes celles qui ont adopté sudo en version >= 1.9.14 et <= 1.9.17, donc en particulier :

• Alma Linux 8, Alma Linux 9 e Alma Linux 10
• Linux rocheux 8/9;
• RHEL 8/9, si mis à jour avec sudo récent;
• Ubuntu (en particulier les versions 22.04 LTS mises à jour) ;
• Tests Debian/Sid, si vous avez reçu la version 1.9.14+ ;
• macOS Séquoia et les versions récentes qui intègrent sudo mis à jour ;
• SUSE Linux Entreprise e openSUSE récente.

CentOS 7 : Hors de danger (pour une fois)

Etrange mais vrai: 7 CentOS, désormais déclaré mort (EOL) depuis juin 2024, est sauvé. La version de sudo inclus dans les dépôts officiels de CentOS 7 est le 1.8.23, sorti vers 2017 et resté disponible jusqu'à la fin du support. Cette version, bien que très datée, n'implémente pas encore l'option --chroot (-R) introduit dans les versions ultérieures de la série 1.9, et pour cette raison même Il n'est pas affecté par la vulnérabilité CVE-2025-32463.

D'un point de vue technique, le code source de sudo 1.8.23 ne prend pas en charge le paramètre --chroot, et il ne dispose pas non plus de routines qui effectuent une commutation temporaire de racine et un chargement de fichiers /etc/nsswitch.conf dans l'environnement chroot. Cela signifie que même si un attaquant tente de créer un environnement manipulé, sudo ne pourrait pas l'utiliser selon la logique vulnérable des versions 1.9.x.

Cependant, il est important de souligner que Ce « sauvetage » est le fruit du hasard et non d’un avantage intrinsèque en matière de sécurité.CentOS 7 est une distribution totalement hors support : ses packages contiennent de nombreuses vulnérabilités connues et non corrigées dans des composants critiques tels que le noyau, glibc, OpenSSL, systemd, OpenSSH et bien d'autres. Continuer à utiliser CentOS 7 en production présente un risque important.

En d’autres termes, pour cette vulnérabilité spécifique, les utilisateurs de CentOS 7 peuvent pousser un soupir de soulagement, mais ils ne devraient pas être considérés comme sûrs dans l'ensembleIl est fortement recommandé de planifier une migration vers une distribution supportée telle qu'AlmaLinux 8/9 ou Rocky Linux 8/9, en profitant des outils de transition mis à disposition par la communauté, comme ELevate d'AlmaLinux.

Comment vérifier si vous êtes vulnérable ?

Faites simplement :

sudo --version

Si vous obtenez un résultat comme :

Sudo version 1.9.17

sei vulnérable.

Si vous avez plutôt :

Sudo version 1.9.17p1

sei déjà en sécurité (version corrigée).

Si vous avez une version plus ancien que 1.9.14 (par exemple 1.8.23 sur CentOS 7), tu n'es pas vulnérable à CVE-2025-32463.

Atténuation immédiate

Si vous ne pouvez pas effectuer la mise à niveau immédiatement, il existe plusieurs moyens d’atténuer les risques :

1. Ne pas autoriser l'accès à sudo aux utilisateurs non fiables

• Supprimer les utilisateurs de /etc/sudoers ou de groupes comme wheel o sudo.
• Utiliser sudoers pour accorder l'accès uniquement à des commandes spécifiques, pas ALL.

2. Évitez d'utiliser --chroot dans vos scripts

Vérifiez s'il existe des scripts ou des tâches cron contenant :

sudo -R

o

sudo --chroot

Si vous n’utilisez pas cette fonctionnalité, vous êtes déjà mieux protégé.

3. Vérifiez les journaux

Recherchez toute utilisation suspecte de --chroot:

grep 'sudo' /var/log/secure | grep '\-\-chroot'

o

journalctl | grep 'sudo.*--chroot'

4. Recompiler sudo dans la bonne version

Alternativement, si votre système ne dispose pas encore de la bonne version de sudo (1.9.17p1 ou supérieur) et que vous ne voulez pas ou ne pouvez pas attendre la mise à jour officielle via le gestionnaire de paquets, vous pouvez télécharger les sources depuis le site officiel et procéder à la compilation manuelle.

Voici les étapes essentielles :

wget https://www.sudo.ws/dist/sudo-1.9.17p1.tar.gz
tar xzf sudo-1.9.17p1.tar.gz
cd sudo-1.9.17p1
./configure --prefix=/usr/local
make
make install

Cela va installer sudo dans l'annuaire /usr/local/bin/sudo, laissant la version du système intacte dans /usr/bin/sudoIl est conseillé de mettre également à jour le PATH ou créez un lien symbolique si vous souhaitez remplacer la version par défaut.

Si vous souhaitez intégrer sudo compilé avec PAM, la journalisation ou des plugins avancés, vous pouvez personnaliser le ./configure avec des options comme :

./configure --prefix=/usr/local --with-pam --with-env-editor --with-logging=syslog

Vous pouvez également valider l'installation avec :

/usr/local/bin/sudo --version

⚠️ Attention: la compilation manuelle de sudo Les interventions sur les systèmes de production doivent être effectuées avec une extrême prudence. Il est conseillé :

• tester d'abord dans des environnements de test ou de laboratoire ;
• faites une sauvegarde complète de votre système ou au moins /etc/sudoers;
• Évitez de désinstaller la version système sans vérifier que la version compilée fonctionne correctement.

Enfin, n’oubliez pas de mettre à jour vos politiques. sudoers si vous utilisez des chemins personnalisés pour la piste sudo (Par ex. /usr/local/bin/sudo).

Un avenir sans --chroot?

Les mainteneurs de sudo ils ont déjà annoncé que l'option --chroot sera supprimé dans les futures versions du logiciel. Cette décision découle du fait que, malgré son utilité apparente dans les scénarios de récupération ou de maintenance, cette option s'est avérée trop complexe à gérer en toute sécurité. Le bug récemment découvert le confirme : la combinaison de l'environnement chroot et de la résolution dynamique des configurations et des bibliothèques peut introduire des vecteurs d'attaque difficiles à atténuer.

Le mécanisme --chroot exige que sudo Il se comporte correctement même dans des environnements artificiels et potentiellement incomplets, ce qui complexifie considérablement la logique du code et augmente la surface d'attaque. De plus, de nombreuses distributions et environnements réels utilisent cette option de manière limitée, ce qui en fait une cible secondaire en termes de fonctionnalités, mais une cible principale en termes de risques.

Pour ceux qui en ont besoin exécuter des commandes dans des environnements isolés ou chroot, il est recommandé d'adopter des outils modernes et nativement plus sécurisés tels que :

• systemd-nspawn: pour lancer des conteneurs Linux légers dans des environnements avec systemd, avec isolation avancée et journalisation intégrée ;
• Chroot géré manuellement: si strictement nécessaire, mais uniquement dans des environnements contrôlés et avec un système de fichiers minimal bien configuré ;
• Conteneurs Docker o Podman: pour exécuter des processus dans des environnements isolés, avec un meilleur contrôle, une meilleure portabilité et des outils de sécurité consolidés.

L'avenir de sudo Elle sera donc plus légère, centrée sur les fonctionnalités essentielles et les politiques granulaires, tandis que l'exécution dans les environnements virtualisés sera confiée à des solutions spécifiquement conçues à cet effet. Une approche compréhensible et, au vu des événements, tout à fait appropriée.

Conclusion : Rafraîchissons sudo

En cet été torride de 2025, même sudo il a commencé à transpirer : une vulnérabilité simple à exploiter mais potentiellement dévastatrice a mis en évidence à quel point il est important de toujours maintenir les outils système à jour, même les « historiques » comme sudo. Le bug lié à l'option --chroot, qui a frappé de nombreuses distributions parmi les plus récentes, a montré comment même les logiciels matures et consolidés peuvent cacher des pièges s'ils ne sont pas correctement entretenus.

Et si certains systèmes anciens sont sauvés par un pur hasard du temps, le constat global reste alarmant : la confiance dans les logiciels à privilèges ne peut jamais être aveugle. Les environnements de production doivent être constamment surveillés, mis à jour et vérifiés. Aucun composant ne doit être tenu pour acquis, surtout s'il a le pouvoir de transformer un utilisateur normal en root.

Le conseil est simple mais stratégique : vérifier la version de sudo, mettre à jour si nécessaire, restreindre l'accès des utilisateurs et surveiller les journauxAjoutez des contrôles à vos audits, supprimez les éléments inutiles dans les politiques sudoers et envisagez également d’adopter des outils plus granulaires pour le contrôle d’accès privilégié.

Et pourquoi pas, au cas où, offrir une serviette à vos serveurs : cet été, eux aussi transpirent. Mais avec les bonnes mises à jour, au moins, ils éviteront le coup de chaud du CVE.