OpenSSH : bypass auth musl libc — Alpine Linux exposé

Les faits

Une vulnérabilité d authentification non documentée affectant OpenSSH sur les systèmes Linux utilisant la bibliothèque C musl a été divulguée le 5 novembre 2026 par le chercheur en sécurité Ozgun Kultekin. Surnommée « *sshole » par son découvreur, cette faille permet à un attaquant de s authentifier par mot de passe sur un compte SSH dont l authentification par mot de passe est officiellement désactivée — c est-à-dire un compte dont le hash de mot de passe dans /etc/shadow est la valeur * (astérisque). La faille n a pas encore reçu d identifiant CVE officiel au moment de la publication, mais son impact potentiel est significatif pour les environnements Linux légers, notamment les distributions Alpine Linux largement utilisées dans les conteneurs Docker et les instances cloud.

La root cause de cette vulnérabilité est subtile et implique une interaction inattendue entre OpenSSH, la bibliothèque cryptographique musl et une décision de conception datant de 2016. Lorsqu un utilisateur tente de se connecter par SSH avec un mot de passe, OpenSSH hache ce mot de passe à l aide de la fonction crypt() et compare le résultat au hash stocké dans /etc/shadow. Pour les comptes dont le hash est * — ce qui signifie que l authentification par mot de passe est désactivée — OpenSSH ne rejette pas immédiatement la tentative. Au lieu de cela, depuis le correctif CVE-2016-6210, OpenSSH hache quand même le mot de passe soumis pour normaliser le temps de réponse et empêcher l énumération de noms d utilisateurs valides par analyse temporelle.

Le problème survient avec la bibliothèque musl, qui contrairement à glibc, retourne la valeur * lorsque la fonction crypt() échoue — notamment lorsque le mot de passe soumis dépasse la limite de 256 octets de musl. Dans ce cas, OpenSSH compare le * retourné par crypt() (signe d échec de hachage) au * stocké dans /etc/shadow (signe de compte désactivé), et les deux valeurs correspondent. L authentification réussit alors à tort. L attaque est donc simple : soumettre un mot de passe arbitraire d une longueur supérieure à 256 octets sur un compte SSH dont le hash est *.

La faille a été découverte par Ozgun Kultekin grâce à une approche originale : il a développé un système d agents IA qui ont exécuté environ 17 600 tests d authentification sur des configurations OpenSSH variées, combinant différents types de hashes de mots de passe malformés et des mots de passe de tailles variables. Ce processus de fuzzing semi-automatisé a permis d identifier l interaction anormale entre les mots de passe surdimensionnés et les hashes * spécifiquement dans les configurations musl. Les détails techniques ont été publiés sur le site sshhole.com par le chercheur le 5 novembre 2026.

Les préconditions exactes pour l exploitation sont les suivantes. Premièrement, OpenSSH doit s exécuter sur un système Linux utilisant musl comme bibliothèque C standard — Alpine Linux, OpenWrt, Buildroot ou Yocto. Deuxièmement, PAM (Pluggable Authentication Modules) doit être désactivé, ce qui est la configuration par défaut du paquet openssh-server d Alpine Linux. Troisièmement, PasswordAuthentication doit être activé dans la configuration SSH. Quatrièmement, au moins un compte avec * comme valeur dans le champ de hash de mot de passe dans /etc/shadow — correspondant aux comptes désactivés ou aux comptes système sans mot de passe. Cinquièmement, un autre compte sur le même système avec un hash de mot de passe valide. Cette dernière condition est requise car OpenSSH ne déclenche le comportement de hachage de normalisation que si au moins un compte avec un hash valide existe sur le système.

L exposition est particulièrement préoccupante pour Alpine Linux, la distribution Docker de référence utilisée dans des millions de conteneurs en production dans le monde entier. Les images officielles Alpine pour AWS et Azure incluent par défaut un compte alpine avec le hash * et des droits doas (équivalent sudo), selon le chercheur. Si des services SSH sont exposés sur ces instances — même temporairement pour du débogage — un attaquant pourrait s authentifier sans connaître de mot de passe valide. Les environnements OpenWrt (routeurs et équipements réseau embarqués) sont également à risque, notamment les modèles exposant SSH sur leurs interfaces de gestion.

La faille existe depuis 2016, date à laquelle la correction de CVE-2016-6210 a introduit le comportement de hachage de normalisation dans OpenSSH. Cela signifie que des milliers d environnements basés sur Alpine Linux ont potentiellement été exposés pendant 10 ans sans que cette vulnérabilité soit détectée. Il n existe actuellement aucune preuve d exploitation active dans la nature, et aucun PoC public n a été mis à disposition par le chercheur au moment de la divulgation, ce qui laisse un délai de remédiation avant une exploitation généralisée potentielle.

Du point de vue de la classification, si un CVE venait à être attribué, la vulnérabilité correspondrait probablement à CWE-287 (Improper Authentication) ou CWE-303 (Incorrect Implementation of Authentication Algorithm). L impact est un accès SSH non autorisé sur des comptes normalement désactivés. Dans les pires configurations — comme les images cloud Alpine avec le compte alpine disposant de droits doas — l exploitation directe peut mener à une compromission root complète du serveur sans élévation de privilèges supplémentaire.

Impact et exposition

L impact primaire de cette vulnérabilité est un accès SSH non autorisé à des comptes dont l authentification par mot de passe est officiellement désactivée. Dans un contexte de conteneurs Docker basés sur Alpine, cela peut permettre à un attaquant ayant accès réseau au port SSH d un conteneur de s y connecter et d exécuter des commandes. Dans un contexte d instance cloud, l accès SSH sur le compte alpine avec droits doas peut mener à une compromission root complète du serveur.

La surface d attaque est étendue en raison de la popularité d Alpine Linux comme image de base Docker. Des millions de conteneurs en production utilisent Alpine comme OS de base. Si des services SSH sont activés — même ponctuellement — dans ces conteneurs, ils sont vulnérables. Les environnements de CI/CD utilisant des runners Alpine avec SSH activé pour le débogage, les environnements de développement, et les instances cloud légères basées sur Alpine sont particulièrement exposés.

Les équipements réseau sous OpenWrt constituent une seconde surface d attaque significative. De nombreux routeurs domestiques et professionnels exposent SSH sur leur interface de gestion. Si leur firmware OpenWrt inclut une version d OpenSSH non patchée et que la configuration SSH correspond aux préconditions décrites, l accès à l interface d administration est possible sans authentification valide. Les modèles en fin de vie ne recevront probablement pas de mise à jour de firmware corrigeant cette faille.

En termes de détection, l exploitation laisse une trace dans les logs système : un login SSH réussi sur un compte dont le hash est * apparaît dans /var/log/messages (sur Alpine) comme « Accepted password » pour ce compte. Les systèmes de monitoring de logs correctement configurés peuvent détecter cette anomalie. L absence de trace dans les logs SSH d une tentative d authentification préalable échouée suivie d un succès immédiat avec un mot de passe long est un indicateur de compromission potentiel.

Recommandations immédiates

• Mettre à jour OpenSSH vers la version 10.6p2 : sur Alpine Linux, exécuter apk upgrade openssh puis redémarrer le service SSH
• Mitigation immédiate si mise à jour impossible : ajouter PasswordAuthentication no dans /etc/ssh/sshd_config et recharger SSH avec service sshd restart
• Inventorier les comptes avec hash * dans /etc/shadow sur tous les systèmes musl : grep ":*:" /etc/shadow
• Vérifier les logs SSH pour des authentifications réussies suspectes : grep "Accepted password" /var/log/messages — si un compte avec hash * apparaît, le système est probablement compromis
• Sur les images Docker Alpine : revoir les Dockerfiles pour désactiver SSH ou imposer uniquement l authentification par clé publique
• Préférer l authentification par clé publique SSH (PubkeyAuthentication) et désactiver définitivement PasswordAuthentication sur tous les serveurs accessibles depuis Internet