Faille critique d'OpenSSH sur Alpine Linux permettant la connexion avec des mots de passe longs

Une vulnérabilité critique dans OpenSSH permet aux attaquants de contourner l'authentification sur certaines configurations d'Alpine Linux en soumettant des mots de passe excessivement longs. Le projet OpenSSH a publié la version 10.6p2 le 5 novembre 2026 pour résoudre ce problème, tandis qu'Alpine Linux a rétroporté les correctifs vers toutes les versions prises en charge.

Ce qui s'est passé

Les attaquants disposant d'un accès réseau peuvent se connecter à des comptes utilisateurs n'ayant aucun mot de passe défini, tels que les utilisateurs authentifiés uniquement par clé SSH ou l'utilisateur alpine par défaut dans les images cloud. Pour réussir, l'attaquant doit connaître le nom du compte et fournir un mot de passe dont la longueur est comprise entre 257 et 1 024 octets. Cette faille affecte spécifiquement les systèmes exécutant le paquet standard openssh-server sur Alpine Linux, lequel est compilé sans l'interface PAM (Pluggable Authentication Module).

La vulnérabilité résulte d'une interaction entre la logique de vérification des mots de passe d'OpenSSH et musl, la bibliothèque C utilisée par Alpine. Lorsque l'authentification par mot de passe est activée et qu'au moins un autre compte local possède un hachage de mot de passe, le serveur accepte incorrectement le mot de passe long pour tout compte dont le champ de mot de passe est vide. Bien qu'aucune exploitation active n'ait été signalée, l'équipe OpenSSH a classé cette faille comme critique et a recommandé des mesures immédiates.

Damien Miller, du projet OpenSSH, a souligné l'urgence, déclarant que les administrateurs doivent « définir PasswordAuthentication=no ou désactiver SSH pour ces systèmes IMMÉDIATEMENT ». Le correctif a été publié rapidement, Miller notant que les longues périodes d'embargo sont de plus en plus dangereuses car les agents IA peuvent redécouvrir de tels bugs en quelques heures.

Comment cela fonctionne

La cause profonde réside dans la manière dont sshd gère la vérification des mots de passe lorsque PAM n'est pas utilisé. Normalement, sshd hache le mot de passe fourni à l'aide de la fonction crypt() et le compare au hachage stocké dans /etc/shadow. Les comptes sans mot de passe ont un caractère * dans ce champ. Comme * est trop court pour contenir un sel, sshd emprunte le sel d'un autre compte qui possède bien un hachage de mot de passe.

Lorsqu'un attaquant soumet un mot de passe supérieur à 256 octets, la fonction crypt() de musl refuse de le traiter et renvoie * pour signaler une erreur. Puisque le champ stocké pour le compte cible est également *, la comparaison réussit et le serveur accorde l'accès. Ce comportement découle d'une modification apportée à musl en 2012, conçue pour empêcher les plantages dans les programmes ne vérifiant pas les échecs de crypt(), combinée à une modification d'OpenSSH en 2016 destinée à prévenir l'énumération des noms d'utilisateurs.

La nouvelle version, 10.6p2, introduit une solution de contournement qui rejette toute correspondance si le champ de mot de passe stocké contient moins de quatre caractères. Bien que cela bloque l'attaque, l'équipe OpenSSH note que le problème sous-jacent réside dans la gestion des entrées longues par la bibliothèque C plutôt que dans SSH lui-même.

Détails clés

• Systèmes affectés : Alpine Linux exécutant openssh-server sans PAM, ou openssh-server-pam avec UsePAM no.
• Prérequis : PasswordAuthentication doit être réglé sur yes, au moins un compte doit posséder un hachage $5$ ou $6$, et le compte cible doit avoir * dans son champ de mot de passe.
• Vecteur d'attaque : Une seule tentative de connexion avec un mot de passe compris entre 257 et 1 024 octets réussit systématiquement.
• Cibles à haut risque : L'utilisateur alpine dans les images tiny-cloud (versions 3.18.11 à 3.24.3) est vulnérable dès qu'un hachage de mot de passe existe sur le système, permettant potentiellement un accès root via doas.
• Systèmes non affectés : Les distributions Linux utilisant glibc, les systèmes utilisant PAM pour l'authentification, et les appareils OpenWrt utilisant Dropbear.
• Disponibilité du correctif : OpenSSH 10.6p2 est disponible maintenant ; Alpine a mis à jour les paquets pour les versions 3.16 à 3.24.

Pourquoi c'est important

Pour les ingénieurs construisant des infrastructures sur Alpine Linux, cette vulnérabilité compromet la sécurité des configurations d'authentification par clé uniquement. De nombreux développeurs comptent sur Alpine pour son empreinte réduite dans les conteneurs et les instances cloud, supposant souvent que la désactivation des connexions par mot de passe ou l'utilisation de clés SSH offre une protection suffisante. Cependant, comme PasswordAuthentication est activé par défaut dans de nombreuses configurations, ces systèmes restent exposés tant qu'ils ne sont pas explicitement durcis.

Cet incident met également en lumière la pression croissante exercée sur les mainteneurs open source pour publier des correctifs rapidement. La décision de passer outre un embargo traditionnel reflète un paysage de menaces en mutation où les outils automatisés peuvent rétro-concevoir les vulnérabilités rapidement. Les équipes doivent désormais prioriser des cycles de patching rapides et considérer que les détails techniques des failles critiques pourraient devenir publics presque immédiatement après leur découverte.

Que pouvez-vous faire

• Mettez à jour vos paquets Alpine immédiatement en utilisant apk upgrade -U -a et redémarrez le service SSH avec rc-service sshd restart.
• Si vous ne pouvez pas mettre à jour tout de suite, désactivez l'authentification par mot de passe en définissant PasswordAuthentication no dans votre configuration SSH.
• Vérifiez vos modifications de configuration en exécutant sshd -T | grep -i passwordauthentication pour vous assurer que cela retourne no.
• Consultez /var/log/messages pour repérer les entrées indiquant Accepted password for concernant des utilisateurs comme root ou alpine qui ne devraient pas avoir d'accès par mot de passe.
• Passez en revue l'utilisation de doas et les utilisateurs récemment créés sur toute machine potentiellement exposée, en les considérant comme compromises si une activité suspecte est détectée.
• Auditez les autres systèmes basés sur musl comme Buildroot ou Yocto s'ils exécutent OpenSSH, bien qu'OpenWrt soit généralement sûr s'il utilise Dropbear.