Une faille dans Alpine Linux permet de se connecter avec un mot de passe trop long Un contournement plus qu’un correctif Illustration : Flock Vincent Hermann Le 06 novembre à 12h10 Une énorme faille de sécurité a été découverte et corrigée dans OpenSSH, qui permet d’administrer à distance la plupart des serveurs Linux. Exploitée, elle pouvait laisser entrer des pirates sur des serveurs Alpine Linux sans besoin de connaitre le mot de passe : il suffisait d’en écrire un aléatoire d’au moins 256 caractères. Une erreur ?
Le projet OpenSSH a publié en urgence un correctif pour la faille dès le 5 novembre. Selon le message de Damien Miller, l’un des principaux développeurs, le correctif a été proposé moins de 24 heures après la réception du signalement. L’équipe d’OpenSSH demande aux administrateurs concernés de couper aussi rapidement que possible la connexion par mot de passe, voire le service SSH lui-même, tant que le correctif n’est pas installé.
Damien Miller indique que la grande majorité des systèmes d’exploitation ne sont pas concernés : Windows, macOS, la plupart des distributions Linux (comme Debian, Ubuntu, Red Hat, Fedora…) ou encore les systèmes BSD ne présentent pas de risque d’exploitation dans leur configuration par défaut. Pourquoi une telle urgence dans ce cas ? Parce que pour être exploitée, la faille nécessite une configuration précise, qui est justement celle par défaut dans Alpine Linux.
Or, cette distribution est souvent utilisée pour sa légèreté dans certains environnements, notamment cloud. Sur Alpine Linux, un correctif à installer au plus vite Dans l’avis publié par l’équipe d’Alpine Linux hier soir, on peut lire qu’un serveur sous Alpine Linux est vulnérable s’il réunit trois conditions : le service SSH accepte les connexions par mot de passe (c’est le cas par défaut), il existe au moins un compte sans mot de passe, et au moins un autre compte en possède un. Si vous estimez que personne n’utilise des comptes sans mot de passe, détrompez-vous.
Il s’agit le plus souvent de comptes auxquels les propriétaires se connectent avec une clé cryptographique, la méthode étant d’ailleurs plus sûre. La vulnérabilité, référencée CVE-2026-123158, peut donc être exploitée pour ouvrir l’accès à ces comptes sans mot de passe, clé cryptographique ou pas. Tout ce dont le pirate a besoin selon Alpine, c’est de joindre le serveur par le réseau et de connaitre le nom d’un de ces comptes.
Sur cette distribution, le compte administrateur (root) est livré sans mot de passe, le rendant en théorie vulnérable. Par défaut, OpenSSH refuse toute connexion par mot de passe au compte administrateur, quel que soit le mot de passe tapé. C’est en théorie suffisant.
Cette protection tombe toutefois si un autre compte a les droits nécessaires pour devenir administrateur. C’est le cas dans les versions 8.18.11 à 3.24.3 des images d’Alpine Linux destinées au cloud. Dès lors, ces machines deviennent vulnérables dès qu’un mot de passe est défini sur un autre compte, ouvrant la voie au pirate pour un accès complet au serveur.
Comme l’indique The Hacker News, il est recommandé de vérifier si d’autres systèmes sont concernés, car le composant impliqué (musl) est aussi utilisé dans des distributions spécialisées dans l’embarqué comme OpenWrt, Buildroot et Yocto. En revanche, les conteneurs Docker qui ne font pas tourner de serveur SSH, les serveurs où la connexion par mot de passe est désactivée, et les machines installées via cloud-init (qui désactive cette connexion) ne sont pas affectés. Comment un mot trop long peut-il ouvrir la porte ?
Un système ne stocke pas les mots de passe en clair. Il ne conserve que leur empreinte, calculée via une transformation mathématique irréversible. Pour vérifier un mot de passe, le serveur calcule l’empreinte de ce qui a été tapé et la compare simplement à celle enregistrée sur la machine.
La vulnérabilité réside dans la rencontre entre deux conventions, qui n’ont rien d’anormal quand elles sont prises isolément. Ainsi, pour un compte sans mot de passe, Linux enregistre un unique astérisque à la place de l’empreinte. Mais Alpine utilise la bibliothèque musl, pour des besoins de légèreté.
Celle-ci, quand elle doit calculer l’empreinte d’un mot de passe de plus de 256 caractères, refuse. Pour signaler l’erreur, elle renvoie… un simple astérisque. Le problème est alors évident : le serveur compare les deux, en déduit qu’il s’agit de la même empreinte et ouvre la session.
Pour effectuer ce calcul, le serveur emprunte un paramètre depuis un compte possédant un vrai mot de passe, d’où la nécessité d’avoir au moins un tel compte configuré. Les distributions n’utilisant pas musl ne sont pas touchées car leur bibliothèque système signale l’erreur autrement. Celles qui délèguent la vérification à un module d’authentification séparé (PAM) ne sont pas non plus concernées.
Ce comportement dans musl remonte à 2012, tandis que la manière dont OpenSSH traite les comptes sans mot de passe vient d’un changement introduit en 2016. La faille existe donc depuis une décennie environ. Le correctif d’OpenSSH refuse désormais toute comparaison avec une empreinte enregistrée trop courte pour être valide.
OpenSSH le présente d’ailleurs davantage comme un contournement, la cause profonde restant dans musl. À noter que le problème avait été remonté en 2024, l’attitude de musl étant alors jugée incorrecte sur l’utilisation de l’astérisque. Les actions à réaliser Sans surprise, la meilleure parade est la mise à jour, mais il faudra redémarrer le service SSH ensuite, car l’installation seule du correctif n’est pas suffisante si le serveur est actif.
Alpine a publié des paquets corrigés pour toutes ses versions depuis la 3.16, y compris celles qui ne sont plus officiellement suivies, comme la 3.21 (son support est terminé depuis le 1ᵉʳ novembre), signe de l’importance de la situation. Les nouvelles versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent directement la correction. Comme indiqué précédemment, sur les machines où la mise à jour est impossible pour le moment, il suffit de désactiver la connexion par mot de passe.
Alpine recommande d’ailleurs de bien vérifier que la connexion par clé cryptographique fonctionne avant de procéder, pour ne pas se retrouver bloqué hors du serveur. Dans les installations cloud, il faudra s’assurer que toutes les machines virtuelles lancées sont corrigées, car la simple reconstruction des images ne protège pas les instances déjà actives. On notera enfin que tout le monde ne semble pas d’accord sur le niveau de dangerosité de cette faille.
Sur le site du NIST, le score CVSS est en effet de 8,1, ce qui la classe comme « élevée », pas « critique ». Dans son message, Damien Miller (de l’équipe OpenSSH) évoque pourtant bien une faille critique. Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker.
Soutenez le journalisme tech de qualité en vous abonnant. Accédez en illimité aux articles d'un média expert Profitez d'au moins 1 To de stockage pour vos sauvegardes Intégrez la communauté et prenez part aux débats Partagez des articles premium à vos contacts Abonnez-vous Nozalys Premium Il y a 46 minutes Voir les réponses Message 1 Aller au commentaire enfant Signaler Bloquer cet utilisateur AUtant je n'ai aucun doute sur la gravité/sévérité de cette faille, autant, pour une fois, je trouve qu'elle est drôle. Le mécanisme qui conduit à la faille, en tout cas, m'amuse !
Alfred1664 Premium Il y a 13 minutes En réponse à Message 1.1 Signaler Bloquer cet utilisateur En effet, ça m’a musl aussi !Sinon, qui utilise Alpine avec SSH ? C’est généralement utilisé pour des conteneurs, non ? Aristide Rutilant Premium Il y a 31 minutes Message 2 Signaler Bloquer cet utilisateur On dirait un accident d’avion moderne : un ensemble de petits incidents sans importance pris séparément et qui mènent à une catastrophe une fois mis ensemble dans les mauvaises circonstances.
TheKillerOfComputer Il y a 22 minutes Message 3 Signaler Bloquer cet utilisateur J'avais vu cela dans mon fil X, je pensais que c'était un fake tant c'était gros SebGF Premium Modifié à l'instant Message 4 Historique Signaler Bloquer cet utilisateur Une énorme faille de sécurité a été découverte et corrigée dans OpenSSH, qui permet d’administrer à distance la plupart des serveurs Linux. Exploitée, elle pouvait laisser entrer des pirates sur des serveurs Alpine Linux sans besoin de connaitre le mot de passe : il suffisait d’en écrire un aléatoire d’au moins 256 caractères.Amusant, ça m'a rappelé un cas plus ou moins similaire sous AIX 5 à l'époque où il y avait un mode de compatibilité (un truc du genre) qui faisait que le système ne prenait pas en compte des mots de passe de plus de 8 caractères.On avait découvert ça sur une campagne de changement avec des mots de passe applicatifs d'une longueur de 12 dont curieusement la fin n'était jamais prise en compte XDedit Ainsi, pour un compte sans mot de passe, Linux enregistre un unique astérisque à la place de l’empreinte.C'est pour ça qu'il est recommandé de toujours définir un mot de passe sur un utilisateur Linux, même pour un compte applicatif qui se connecte uniquement en SSH. Une chaîne random suffit dans ce cas-là.
Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ? Non Oui