La faille SSHole d'OpenSSH permet un accès root sur Alpine Linux en quelques heures

Des acteurs malveillants ont commencé à exploiter une vulnérabilité critique d'OpenSSH, identifiée sous le nom CVE-2026-123158 et surnommée SSHole, moins de neuf heures après sa divulgation publique. Cette faille permet aux attaquants non authentifiés d'accéder à des comptes configurés sans mot de passe sur certaines distributions Linux, notamment Alpine Linux. Les chercheurs en sécurité ont confirmé l'obtention réussie d'un accès root sur des honeypots, soulignant le risque immédiat pour les infrastructures reposant sur des configurations par défaut.

Ce qui s'est passé

La vulnérabilité affecte les systèmes Linux exécutant OpenSSH sur la bibliothèque C musl avec les modules d'authentification pluggables (PAM) désactivés. Cette configuration est courante dans les distributions légères comme Alpine Linux, qui l'utilise par défaut. Un attaquant peut envoyer un mot de passe surdimensionné, compris entre 257 et 1 024 octets, à un compte n'ayant aucun mot de passe utilisable défini. Au lieu de rejeter la connexion, le système authentifie l'utilisateur par erreur.

Le chercheur en sécurité Ozgun Kultekin a découvert ce problème, qui découle d'un correctif introduit en 2016 pour corriger une autre vulnérabilité, la CVE-2016-6210. Le correctif visant à empêcher l'énumération des noms d'utilisateur a involontairement créé une erreur logique dans la gestion des mots de passe. Lorsque l'opération de hachage échoue en raison d'une entrée trop longue, OpenSSH renvoie un caractère astérisque. Le démon compare ensuite ce résultat à l'astérisque stocké dans le champ du mot de passe des comptes désactivés, interprétant cette correspondance comme une connexion réussie.

L'entreprise de renseignement sur les menaces Previdian a observé la première tentative d'exploitation peu de temps après la publication de la CVE. Les données de télémétrie ont identifié huit tentatives provenant d'une adresse IP géolocalisée au Japon. L'attaquant a utilisé des mots de passe surdimensionnés pour contourner l'authentification et a exécuté des commandes de reconnaissance telles que id, uname et hostname via des sessions SSH non interactives. Previdian a confirmé que ces tentatives ont abouti à un accès root réussi sur un honeypot exécutant Alpine Linux.

Fonctionnement

Le mécanisme central repose sur la manière dont OpenSSH gère la vérification des mots de passe pour les comptes volontairement verrouillés ou configurés sans mot de passe. Dans ces cas, le système stocke un astérisque (*) dans le champ du mot de passe pour indiquer que la connexion par mot de passe est désactivée. Normalement, toute tentative de mot de passe devrait échouer. Cependant, lorsqu'un attaquant fournit une chaîne de mot de passe dépassant la taille tampon attendue, la fonction de hachage interne échoue gracieusement mais renvoie le même caractère astérisque.

Le démon sshd ne fait pas la distinction entre une échec légitime du hachage et le placeholder stocké. Il voit l'astérisque renvoyé par l'opération de hachage échouée et le compare à l'astérisque présent dans le champ du mot de passe du compte. Cette collision logique trompe le module d'authentification qui accorde alors l'accès. L'exploit ne fonctionne que sur les comptes dont le champ du mot de passe est explicitement défini sur un astérisque. Il n'affecte pas les comptes disposant de hachages de mots de passe valides ni ceux utilisant PAM pour les vérifications d'authentification.

Ce comportement est spécifique à l'interaction entre OpenSSH et la bibliothèque C musl. Les systèmes utilisant la bibliothèque glibc, Dropbear SSH ou des systèmes d'exploitation non-Linux ne sont pas affectés. De plus, tout système déléguant la vérification des mots de passe à PAM reste sécurisé car PAM gère la logique de validation différemment, évitant ainsi la comparaison défaillante au sein d'OpenSSH lui-même.

Détails clés

• ID de la vulnérabilité : CVE-2026-123158 avec un score CVSS de 8,1.
• Systèmes affectés : Systèmes Linux utilisant OpenSSH sur musl libc avec PAM désactivé, notamment les configurations par défaut d'Alpine Linux.
• Méthode d'exploitation : Envoi d'un mot de passe arbitraire compris entre 257 et 1 024 octets à un compte où le mot de passe est désactivé.
• Version corrigée : Corrigé dans OpenSSH 10.6p2.
• Exploitation active : Premières tentatives observées moins de neuf heures après la divulgation ; accès root confirmé sur des honeypots.
• Limitations : N'affecte pas les distributions basées sur glibc, Dropbear, ni les systèmes utilisant PAM pour l'authentification.

Pourquoi c'est important

Pour les équipes d'ingénierie gérant des infrastructures cloud, cette vulnérabilité met en évidence les risques associés aux configurations par défaut dans les environnements conteneurs légers. Alpine Linux est largement utilisé dans les conteneurs Docker et les clusters Kubernetes en raison de son empreinte réduite. Si ces instances exposent des ports SSH et reposent sur une authentification par clé uniquement sans désactiver correctement les champs de mot de passe ou activer PAM, elles deviennent vulnérables à une prise de contrôle immédiate. La rapidité de l'exploitation montre que les scanners automatisés ciblent déjà cette faille spécifique.

L'impact va au-delà de l'accès initial. Comme noté par Safe Security, une attaque réussie accorde les permissions du compte compromis. Si la cible est un compte root ou un compte de service avec des privilèges élevés, les attaquants peuvent accéder aux identifiants de déploiement, aux secrets d'application et à l'infrastructure connectée. Cela facilite le mouvement latéral à travers le réseau, pouvant mener à des perturbations généralisées des services ou à une exfiltration de données. Le fait que l'exploit ne nécessite aucune identification volée le rend particulièrement dangereux pour les services exposés.

Ce que vous pouvez faire

• Mettez à jour immédiatement vers OpenSSH 10.6p2 ou appliquez le package corrigé fourni par votre distribution Linux.
• Redémarrez le service sshd après la mise à jour pour vous assurer que la nouvelle version est active.
• Vérifiez /var/log/messages pour repérer les entrées indiquant "Accepted password for" sur des comptes qui ne devraient pas accepter de mots de passe, tels que root ou alpine.
• Examinez l'utilisation de doas, les utilisateurs récemment créés, les fichiers et les clés autorisées sur toutes les machines exposées pour détecter des signes de compromission.
• Si vous ne pouvez pas exclure une connexion non autorisée basée sur les logs, traitez la machine comme compromise et isolez-la.
• Envisagez d'activer PAM si votre distribution le prend en charge, car cela atténue la vulnérabilité en modifiant le flux d'authentification.