TL;DR : L’essentiel
- OpenSSH applique cette vérification erronée uniquement sur les distributions Linux dépourvues de modules PAM, comme Alpine Linux ou OpenWrt.
- Les comptes visés portent une simple étoile dans le fichier d’authentification pour interdire normalement les connexions par mot de passe.
- L’envoi d’une chaîne dépassant 256 octets provoque une réponse identique à cette étoile et valide immédiatement l’accès au système distant.
Des attaquants exploitent activement la vulnérabilité critique SSHole d’OpenSSH pour accéder à des comptes Linux pourtant configurés sans mot de passe, comme l’explique The Hacker News. Découverte en novembre 2026, l’anomalie répertoriée sous l’identifiant CVE-2026-123158 remonte à 2016. Elle découle d’un ancien correctif conçu pour empêcher l’énumération des noms d’utilisateurs. Pour éviter de révéler l’existence d’un compte par des différences de temps de traitement, le serveur calculait une empreinte même si le compte bloquait les connexions. Les systèmes concernés associent OpenSSH, la bibliothèque musl et une configuration sans modules PAM. Des distributions comme Buildroot ou Yocto partagent aussi cette base technique.
La bibliothèque musl sert d’alternative légère à la bibliothèque logicielle standard du système d’exploitation, couramment intégrée dans les environnements compacts et les conteneurs. Le problème réside dans le fonctionnement interne de sa fonction de chiffrement de mot de passe. Quand une chaîne soumise dépasse 256 octets, cette fonction échoue et renvoie un astérisque par défaut. Or, les administrateurs inscrivent précisément un astérisque dans le fichier de configuration pour bloquer l’accès par mot de passe des comptes utilisant des clés d’accès. OpenSSH compare alors l’astérisque renvoyé par l’erreur avec l’astérisque enregistré dans le système, comme le détaille Slashdot. Cette correspondance valide l’accès dès la première tentative, sans affecter les comptes protégés par un mot de passe classique.
L’attaque nécessite également la présence sur le système d’au moins un compte actif dont le mot de passe utilise les fonctions SHA256 ou SHA512, d’après les analyses rapportées par Ars Technica. Si le compte administrateur direct reste protégé sous les configurations d’origine, un compte intermédiaire disposant de droits d’élévation permet d’obtenir un contrôle total. Les administrateurs qui ne peuvent pas installer immédiatement la mise à jour doivent désactiver l’authentification par mot de passe dans les réglages du serveur SSH. L’examen des journaux d’authentification permet aussi de repérer les connexions réussies par mot de passe sur ces comptes spécifiques.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Cette veille vous a fait gagner du temps ?
Offrez un café pour saluer le travail et garder DCOD gratuit et indépendant.