Faille OpenSSH sur Alpine : un mot de passe trop long ouvre des comptes

Le chercheur en sécurité Ozgun Kultekin a publié le 5 novembre 2026 les détails d’une faille qui touche OpenSSH sur les distributions Linux bâties sur la bibliothèque C musl. Selon Bleeping Computer, seule source disponible à ce stade, elle existerait depuis 2016. Le chercheur l’aurait trouvée à l’aide d’agents d’IA qui ont mené environ 17 600 tests d’authentification, en combinant des configurations d’OpenSSH, des empreintes de mot de passe malformées et des mots de passe surdimensionnés.

Un astérisque comparé à un astérisque

Sous Linux, on bloque la connexion par mot de passe d’un compte en remplaçant son empreinte par un astérisque (*) dans /etc/shadow. Ce n’est pas une empreinte valide : en principe, aucun mot de passe ne peut y correspondre.

Le problème viendrait d’un correctif de 2016. Pour empêcher qu’on devine les noms d’utilisateur valides en mesurant les temps de réponse (CVE-2016-6210), OpenSSH calcule depuis une empreinte même pour les comptes qui n’en ont pas d’utilisable, y compris ceux verrouillés par *. Or, sous musl, la fonction crypt() renvoie elle aussi * quand elle échoue, notamment lorsque le mot de passe soumis dépasse sa limite de 256 octets. Il suffirait donc d’envoyer un mot de passe trop long : OpenSSH compare le * renvoyé par crypt() au * stocké, les deux sont identiques, et la session s’ouvre.

La faille ne permet pas de contourner le mot de passe d’un compte doté d’une empreinte valide. Elle ne vise que les comptes verrouillés par un astérisque.

Qui est exposé

D’après le chercheur, l’exploitation suppose que toutes ces conditions soient réunies :

• OpenSSH tourne sur un système musl : Alpine Linux, OpenWrt, Buildroot ou Yocto ;
• l’authentification PAM est désactivée, ce qui est le cas par défaut dans le paquet openssh-server d’Alpine ;
• l’authentification SSH par mot de passe est activée ;
• au moins un compte a un astérisque pour empreinte, et un autre a une empreinte valide.

Le cas le plus sensible concerne les images cloud officielles d’Alpine Linux sur AWS et Azure. Elles comportent par défaut un compte alpine concerné par la faille, qui dispose de privilèges doas sans mot de passe : un attaquant pourrait ainsi obtenir un accès root.

Les systèmes fondés sur glibc, comme Debian, Ubuntu et Fedora, ne sont pas vulnérables, pas plus que ceux qui passent par l’authentification PAM. Si vous administrez une machine sous OpenWrt, Buildroot ou Yocto avec un serveur SSH actif, les mêmes vérifications s’appliquent que pour Alpine.

Vérifier et corriger

Le correctif figure dans OpenSSH 10.6p2. Sur Alpine, la mise à jour se fait par :

apk upgrade openssh

Si vous ne pouvez pas mettre à jour tout de suite, désactivez l’authentification SSH par mot de passe dans la configuration du serveur avec la directive PasswordAuthentication no, puis redémarrez le service SSH. Vous retirez ainsi l’une des conditions nécessaires à l’exploitation.

Chercher des traces

Le chercheur recommande aussi de passer en revue les journaux d’authentification SSH, à la recherche de connexions par mot de passe sur des comptes qui ne devraient pas en accepter. Sur Alpine, cette commande liste les connexions par mot de passe réussies :

grep "Accepted password" /var/log/messages

Si une connexion réussie apparaît pour le compte alpine, vérifiez son champ de mot de passe :

grep '^alpine:' /etc/shadow

Si ce champ contient un astérisque alors que les journaux montrent une connexion par mot de passe acceptée, la faille a peut-être été exploitée. Le même raisonnement vaut pour tout autre compte verrouillé de cette manière.

Pendant dix ans, le verrou d’un compte et le code d’erreur de musl ont porté le même symbole, et ce seul caractère a suffi à ouvrir la porte.