Vulnérabilité critique dans Sudo : CVE‑2025‑32462

Actualités Cyber Sécurité Linux

La commande sudo permet normalement à un utilisateur limité d’exécuter des commandes avec les privilèges root, strictement encadrée par le fichier /etc/sudoers. Mais un bug dans le traitement de l’option -h <hostname> (prévue uniquement pour la commande sudo -l) permet, depuis plus de 12 ans, de contourner ces restrictions.
En abusant de sudo -h dev-server … ou sudoedit -h, l’attaquant peut se faire passer pour un hôte autorisé, et exécuter des commandes root localement, même si cet hôte n’est pas le bon.

Autrement dit, le champ « Host » d’une règle sudoers devient inutile car l’utilisateur peut définir un autre hôte arbitrairement lors de l’exécution

Qui a découvert cette faille ?

  • La faille a été découverte par Rich Mirch, chercheur au sein de la Cyber Research Unit de Stratascale, une équipe spécialisée en cybersécurité offensive et défensive.
  • Elle a été identifiée en juin 2025 lors d’un audit interne. Les détails techniques complets — y compris l’abus de l’option -h — sont exposés dans un advisory officiel publié le 30 juin 2025 par Stratascale. Pour mieux approfondir, voici le lien.

Les Versions concernées par cette faille

  • Sudo stable : versions 1.9.0 → 1.9.17
  • Sudo legacy : versions 1.8.8 → 1.8.32
  • Cette faille touche les distributions Linux les plus répandues (Ubuntu, Debian, Fedora, SUSE…) ainsi que macOS Sequoia, dans la mesure où ces systèmes utilisent une version affectée de sudo.

CVE attribués :

  • CVE‑2025‑32462 → contournement des règles sudoers via -h
  • CVE‑2025‑32463 → bug distinct lié à l’utilisation de chroot

Pourquoi c’est grave ?

Cette vulnérabilité est particulièrement dangereuse pour plusieurs raisons :

  • Elle ne nécessite aucun privilège particulier, ni technique avancée comme un buffer overflow ou une élévation via mémoire corrompue.
  • Il s’agit d’un bug logique : l’attaquant détourne une option prévue pour une autre commande (sudo -l) afin de contourner les règles définies dans /etc/sudoers.
  • Elle est exploitée localement, à partir d’un simple compte utilisateur présent sur la machine — aucun accès root n’est requis au départ.
  • Elle touche potentiellement des millions de systèmes : postes de travail, serveurs, environnements partagés, ou infrastructures cloud.
  • Si des règles sudoers utilisent des Host ou Host_Alias spécifiques, cette faille les rend inefficaces.

Bon à savoir: La configuration doit toutefois contenir des règles sudoers avec un champ d’hôte spécifique (autre que le serveur courant ou “ALL”). Ce scénario se rencontre surtout dans les entreprises qui déploient un fichier sudoers commun sur plusieurs machines ou via LDAP/SSSD openwall.com. Si toutes vos règles utilisent “ALL” pour l’hôte (configuration par défaut sur un seul poste), l’attaque n’aura pas d’effet.

Replay concret (reproduit sur Medium)

Voici un exemple simple mais parlant de la faille en action, basé sur une configuration réaliste souvent utilisée en entreprise :

Le fichier /etc/sudoers contient une règle autorisant l’utilisateur alice à exécuter certaines commandes en tant que root, mais uniquement si elle est connectée au serveur nommé dev-server.

Or, sur un autre serveur du réseau, par exemple prod-server, cette règle ne devrait pas s’appliquer.

Pourtant, en lançant la commande suivante :

sudo -h dev-server cat /etc/shadow

l’utilisateur obtient un accès root localement, sur le mauvais serveur. Comment ? Parce que sudo ne vérifie pas que l’hôte fourni avec -h correspond à la machine actuelle. Il applique naïvement les règles prévues pour dev-server, même si on est sur prod-server.

Résultat : alice lit le fichier /etc/shadow sur prod-server, alors qu’elle n’y était pas autorisée.

Une démonstration complète de cette attaque est visible dans cet article technique sur Medium.

Quelle solution à appliquer ? (MAJ immédiate)

La solution officielle est claire : mettre à jour immédiatement.

  • Le bug a été corrigé dans sudo 1.9.17p1, publié début juin 2025. Cette version désactive complètement l’utilisation abusive de -h, en restreignant son usage strictement à sudo -l.
  • Ce correctif concerne deux failles distinctes mais liées : CVE‑2025‑32462 (contournement des restrictions Host avec -h) et CVE‑2025‑32463 (mauvaise gestion de chroot dans certaines configurations)
  • Les distributions majeures (Ubuntu, Debian, Fedora, SUSE, etc.) ont déjà publié les mises à jour correspondantes dans leurs dépôts officiels.
  • Et non, il n’y a aucun correctif de contournement fiable sans mise à jour : tant que la faille existe, elle est exploitable. À moins de désactiver totalement toutes les règles Host, ce qui peut être risqué selon votre usage.

Ce que TU dois ABSOLUMENT faire

  1. Vérifie ta version de sudo :
sudo --version

2. Si ta version est ≤ 1.9.17, tu es vulnérable, mets à jour immédiatement :

  • Sous Ubuntu/Debian :
sudo apt update && sudo apt install sudo
  • Sous Fedora/SUSE : utilise dnf update sudo ou zypper update sudo

3. Audit des règles sudoers :

  • Ouvre /etc/sudoers et les fichiers dans /etc/sudoers.d/
  • Cherche toute règle contenant un champ Host ou Host_Alias
  • Si tu ne peux pas encore mettre à jour, remplace temporairement les hôtes spécifiques par ALL pour éviter les contournements

4️. Active la surveillance des journaux :

  • Mieux : configure une alerte automatique (fail2ban, auditd…)
  • Surveille les logs /var/log/auth.log ou /var/log/secure
  • Repère toute tentative avec sudo -h ou sudoedit -h

En résumé, En juillet 2025, une faille vieille de 10 ans dans sudo (CVE‑2025‑32462) permet à un simple utilisateur local de devenir root grâce à une mauvaise gestion de l’option -h. Cette vulnérabilité concerne des millions de systèmes Linux et macOS.
Le correctif existe : passer à sudo 1.9.17p1 ou supérieur, disponible dès début juin 2025. Les distributions principales ont déjà déployé leurs mises à jour.
Action à mener immédiatement : vérifier ta version de sudo, installer le patch, auditer tes fichiers sudoers, surveiller les logs. Sécurité maximale sans délai !

Restez protégé ! Partagez cet article si vous êtes admin système, DevOps ou responsable IT, cette faille est un coup de semonce pour tous les environnements Unix/Linux

Share this content:

Contenu similaire

Laisser un commentaire