En bref

  • Une faille dans OpenSSH permet à un attaquant de s'authentifier par mot de passe sur un compte dont le mot de passe est pourtant désactivé, sur les systèmes Linux utilisant musl libc.
  • Systèmes concernés : Alpine Linux, OpenWrt, Buildroot, Yocto — tout OS utilisant musl avec OpenSSH, l'authentification par mot de passe activée et PAM désactivé.
  • Action requise : mettre à jour vers OpenSSH 10.6p2 immédiatement, ou désactiver l'authentification par mot de passe SSH en attendant.

Les faits

Le 5 novembre 2026, le chercheur en sécurité Ozgun Kultekin a rendu publics les détails techniques d'une vulnérabilité affectant OpenSSH sur les systèmes Linux construits avec musl libc. La bibliothèque musl est une alternative légère à glibc, utilisée dans de nombreuses distributions embarquées et orientées minimalisme : Alpine Linux en tête, mais aussi OpenWrt, Buildroot et Yocto. La faille, surnommée « sshhole » par son découvreur, a été corrigée le même jour dans OpenSSH 10.6p2.

Pour comprendre la vulnérabilité, il faut remonter à une décision de conception prise en 2016 lors du correctif CVE-2016-6210. À l'époque, OpenSSH était vulnérable à une attaque par canal auxiliaire temporel : le serveur SSH répondait légèrement plus vite aux tentatives de connexion sur des comptes inexistants ou verrouillés qu'aux comptes avec un mot de passe valide, permettant à un attaquant de confirmer l'existence d'un compte par simple mesure du temps de réponse. Pour neutraliser ce timing oracle, les développeurs d'OpenSSH ont introduit un mécanisme de hachage factice : même pour un compte dont le mot de passe est désactivé, le serveur calcule un hash du mot de passe fourni afin d'uniformiser le temps de traitement.

C'est précisément ce mécanisme de défense qui crée la nouvelle vulnérabilité. Sous musl libc, la fonction crypt() se comporte différemment de son équivalent glibc lorsqu'elle traite un mot de passe dépassant 256 octets. Sur un système glibc, crypt() calcule normalement le hash même pour un mot de passe long. Sur musl, au-delà de 256 octets, crypt() ne calcule pas le hash et renvoie à la place la chaîne *. Or, * est précisément la valeur stockée dans /etc/shadow pour les comptes verrouillés ou désactivés. La comparaison entre le résultat de crypt() sur un mot de passe long (*) et le hash stocké pour un compte verrouillé (*) est donc positive : OpenSSH authentifie l'utilisateur.

Pour qu'une exploitation réussisse, quatre conditions doivent être réunies simultanément. Premièrement, PAM doit être désactivé dans la configuration OpenSSH — c'est le comportement par défaut du paquet openssh-server d'Alpine Linux. Deuxièmement, l'authentification par mot de passe doit être activée dans sshd_config. Troisièmement, le système doit comporter au moins un compte dont le hash stocké dans /etc/shadow est *. Quatrièmement, un autre compte doit posséder un hash valide — condition nécessaire pour que le mécanisme anti-timing s'active. Sur Alpine Linux, le paquet openssh-server désactive PAM par défaut, ce qui en fait le système le plus exposé de loin.

La méthodologie de découverte mérite d'être soulignée. Kultekin a utilisé des agents IA qui ont exécuté environ 17 600 tests d'authentification automatisés pour explorer les comportements anormaux d'OpenSSH dans des conditions de hachage dégradées. Cette approche illustre la montée en puissance de l'IA dans la recherche offensive, et rappelle que les chercheurs en sécurité adversariaux disposent désormais d'outils capables d'explorer des espaces de vulnérabilités bien plus larges qu'une équipe humaine ne pourrait le faire manuellement.

L'impact potentiel est particulièrement préoccupant pour les déploiements cloud Alpine. Les images officielles d'Alpine pour AWS et Azure incluent par défaut un compte nommé alpine avec des droits doas (l'équivalent sudo sur Alpine) sans mot de passe. Si ce compte dispose d'un hash * dans /etc/shadow et que les quatre conditions précédentes sont réunies, un attaquant peut s'authentifier sur ce compte en envoyant un mot de passe de plus de 256 octets, puis obtenir les droits root via doas en une seule commande supplémentaire. L'escalade vers root serait donc triviale sur ces environnements cloud Alpine non durcis.

Du côté d'OpenWrt, Buildroot et Yocto, les mêmes conditions s'appliquent si ces firmwares embarquent OpenSSH avec une configuration similaire. Les routeurs, points d'accès et appliances réseau sous OpenWrt sont particulièrement concernés dès lors que l'administration SSH par mot de passe est activée, situation courante dans les déploiements industriels et chez les petits opérateurs qui n'ont pas migré vers l'authentification par clé.

Les systèmes Debian, Ubuntu, Fedora et toute distribution basée sur glibc ne sont pas affectés : sur ces OS, crypt() gère correctement les mots de passe longs et ne renvoie jamais *. Les systèmes utilisant PAM pour l'authentification SSH sont également protégés, PAM implémentant ses propres vérifications qui détectent les comptes verrouillés avant que OpenSSH ne compare les hashes. Les systèmes configurés avec PasswordAuthentication no ne sont pas non plus exposés.

Un élément important à souligner est la portée des images Docker Alpine sur les pipelines CI/CD modernes. Alpine est de loin la distribution la plus utilisée comme base d'images Docker en raison de sa légèreté — une image Alpine pèse environ 5 Mo contre 70 Mo pour une image Debian slim. Des centaines de milliers de conteneurs applicatifs sont basés sur alpine, mais la grande majorité n'exposent pas SSH. En revanche, les images Alpine utilisées comme jump hosts, bastions SSH, runners CI avec accès SSH, ou images de base pour des services d'administration sont potentiellement vulnérables. Les équipes DevOps utilisant Alpine comme système d'exploitation pour leurs pipelines avec accès SSH doivent vérifier en priorité leurs configurations.

Impact et exposition

L'exposition directe dépend de plusieurs paramètres cumulatifs : la présence d'Alpine Linux ou d'un système musl dans l'infrastructure, l'activation de l'authentification par mot de passe SSH, et la désactivation de PAM. Sur le cloud, les instances EC2 et Azure VM basées sur les images officielles Alpine sont dans le périmètre si l'authentification par mot de passe SSH est activée. Sur le marché des équipements réseau, les routeurs OpenWrt accessibles depuis internet avec l'administration SSH exposée constituent un vecteur d'attaque direct sur des équipements rarement mis à jour aussi rapidement que des serveurs de production. Les environnements edge computing et IoT industriels utilisant des images musl légères sont également dans le périmètre.

Recommandations

  • Mettre à jour OpenSSH vers la version 10.6p2 immédiatement sur tous les systèmes Alpine Linux : apk upgrade openssh.
  • En urgence, sans attendre le patch : désactiver l'authentification par mot de passe SSH en ajoutant PasswordAuthentication no dans /etc/ssh/sshd_config et redémarrer sshd.
  • Vérifier les logs SSH pour détecter des connexions suspectes réussies : grep "Accepted password" /var/log/messages.
  • Auditer le compte alpine sur toutes les instances cloud : grep '^alpine:' /etc/shadow et le verrouiller si inutilisé.
  • Inventorier tous les conteneurs Docker basés sur alpine:* et les firmwares OpenWrt dans le parc pour prioriser les mises à jour.
  • Migrer vers l'authentification exclusive par clé SSH, indépendamment de cette vulnérabilité.

Mes conteneurs Docker Alpine sont-ils exposés si SSH n'est pas installé ?

Non. La vulnérabilité ne concerne que les systèmes où OpenSSH server est installé et actif avec authentification par mot de passe et PAM désactivé. La grande majorité des conteneurs applicatifs Alpine n'exposent pas SSH et ne sont pas concernés. En revanche, les images Alpine utilisées comme jump hosts ou bastions SSH doivent être mises à jour en priorité.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit