Le scénario cauchemardesque parfait pour un serveur Linux, c'est quand tout ce dont un attaquant a besoin est d'atteindre le port Secure Shell (SSH) du serveur, d'entrer tranquillement et d'en prendre le contrôle. C'est ce qui est arrivé à Alpine Linux, la populaire distribution Linux légère pour serveurs. Pour ne rien arranger, cela s'est produit quelques jours seulement après qu'Alpine Linux a esquivé une balle de la taille d'une faille de sécurité dans son implémentation de GitLab.

Comme l'a expliqué l'ingénieur en sécurité Gregory Bryant dans son post LinkedIn : « La plupart des contournements d'authentification proviennent de chaînes logiques complexes, mais la vulnérabilité OpenSSH d'Alpine Linux d'hier (CVE-2026-123158) se résume à un seul caractère : *. »

Si vous exécutez Alpine Linux (ou une autre distribution basée sur musl) avec le paquet openssh-server par défaut (sans Pluggable Authentication Modules, ou PAM) et que PasswordAuthentication est activé, un attaquant peut se connecter à des comptes dont le mot de passe est désactivé, ou à clé uniquement, simplement en envoyant un mot de passe d'une longueur comprise entre 257 et 1024 octets.

Alpine Linux n'est pas le seul système d'exploitation à utiliser musl, une version légère de la bibliothèque C standard (libc). D'autres systèmes d'exploitation qui utilisent musl et sont potentiellement vulnérables incluent Adélie Linux ; Void Linux ; Sabotage Linux ; OpenWrt, une variante d'Android ; et le Yocto Project, utilisé pour construire des distributions Linux embarquées.

Wind River, qui produit la distribution Linux embarquée commerciale Wind River Linux, examine également le problème. Un représentant de l'entreprise m'a déclaré : « Wind River prend la sécurité au sérieux. Nous examinons activement la vulnérabilité signalée et évaluons son impact potentiel. Nous prendrons les mesures appropriées si nécessaire. »

En coulisses, lorsque OpenSSH est compilé sans PAM, il vérifie les mots de passe en hachant la tentative de mot de passe à l'aide de la fonction crypt() de la bibliothèque C. Il compare ensuite le résultat au champ de mot de passe stocké du compte. Jusque-là, tout va bien.

Mais lorsqu'une clé dépasse 256 octets, la fonction crypt() de musl renvoie la chaîne * comme indicateur d'erreur. C'est également ce que contient le champ de mot de passe pour tout compte sans mot de passe, comme un compte à clé uniquement. Ainsi, le « hachage » correspond et la connexion réussit, et l'attaquant entre.

Pour l'exploiter, un attaquant a seulement besoin du nom d'un tel compte. L'attaquant a également besoin d'au moins un autre compte sur la machine avec un hachage de mot de passe de 5 ou 6, puis d'envoyer un mot de passe de 257 à 1 024 octets. Selon Alpine, un seul utilisateur avec un mot de passe suffit pour rendre tous les comptes sans mot de passe accessibles.

Dans les systèmes Linux qui utilisent crypt() de glibc, soit presque tous, la même tentative renverrait NULL en cas d'erreur, ce que sshd rejette déjà, donc Debian, Ubuntu, Fedora, etc., ne sont pas affectés.

Selon *sshole, le groupe qui a découvert le problème, il s'agit d'un effet secondaire qui se cache depuis 2016.

Alpine a déclaré que toutes les versions qu'elle a vérifiées sont affectées : de 3.21 à 3.24, edge, et les anciennes branches 3.16 à 3.20. L'exposition nécessite les éléments suivants :

Root n'est pas directement exposé dans la plupart des cas. Il est livré en tant que root:* dans l'image de base depuis environ Alpine 3.16, mais le PermitRootLogin prohibit-password par défaut d'OpenSSH le bloque. Un autre compte qui peut devenir root, par exemple via doas, donne toujours à un attaquant une voie vers root.

Alpine a particulièrement pointé du doigt ses images officielles tiny-cloud, versions 3.18.11 à 3.24.3, comme étant spécialement vulnérables. Celles-ci sont livrées avec un utilisateur alpine ayant un champ de mot de passe * et doas sans mot de passe. Elles sont sûres au premier démarrage mais deviennent exploitables dès qu'un hachage 6 existe sur la machine. Cela peut se produire lorsqu'un administrateur définit un mot de passe console ou lorsque les données utilisateur ajoutent un utilisateur avec un mot de passe haché, ce qui signifie, essentiellement, toutes.

Alpine a publié les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 jeudi, avec le correctif OpenSSH parmi les changements de sécurité. Elle a également publié des paquets corrigés pour chaque version jusqu'à la 3.16. Alpine 3.21 a atteint sa fin de support le 1er novembre.

La version OpenSSH 10.6p2 tout juste publiée évite le problème dans sshd. Les branches stables d'Alpine portent un correctif pour le même problème. Vous devriez exécuter apk upgrade -U -a puis redémarrer le