OpenSSH, le logiciel qui assure l’essentiel des connexions à distance aux serveurs Linux, a publié le 5 novembre 2026 la version 10.6p2 pour neutraliser une faille OpenSSH qualifiée de critique par ses mainteneurs. Sur les systèmes bâtis avec la bibliothèque musl et sans module PAM, comme Alpine Linux, un attaquant peut ouvrir une session sur un compte verrouillé en tapant simplement un mot de passe de plus de 256 octets.
Le défaut a été découvert par le chercheur Özgün Kültekin, de la société Wakefield, qui l’a baptisé « sshole ». Aucun identifiant CVE, la référence publique attribuée aux vulnérabilités, n’avait encore été communiqué au soir du 6 novembre. Les notes de version d’OpenSSH précisent que la cause profonde se situe hors du programme sshd, mais que celui-ci peut l’éviter, d’où ce correctif de contournement.
Comment fonctionne cette faille OpenSSH ?
Tout part de la fonction crypt(), chargée de calculer l’empreinte d’un mot de passe pour la comparer à celle stockée dans le fichier /etc/shadow. Depuis 2012, la bibliothèque C musl, une alternative légère à la glibc utilisée par la plupart des distributions, ne renvoie plus une valeur vide en cas d’échec : elle renvoie le caractère « * ». Or musl refuse de traiter les mots de passe de plus de 256 octets, une limite posée pour éviter les attaques par déni de service.
Le second ingrédient vient d’OpenSSH lui-même. En 2016, pour empêcher un attaquant de deviner quels comptes existent en mesurant le temps de réponse du serveur (faille CVE-2016-6210), le projet a choisi de calculer une empreinte même pour les comptes qui n’ont pas de mot de passe utilisable. Ces comptes portent justement la marque « * » dans /etc/shadow, ce qui signifie « aucun mot de passe ne peut correspondre ».
Résultat : un mot de passe trop long fait échouer crypt(), qui renvoie « * », et cette valeur coïncide exactement avec celle d’un compte verrouillé. Le serveur conclut à un mot de passe correct.
Les comptes dotés d’un vrai mot de passe ne sont pas concernés, puisque leur empreinte ne vaut jamais « * ». Pour mettre au jour ce comportement, le chercheur a confié à des agents d’IA environ 17 600 tests d’authentification combinant configurations d’OpenSSH, empreintes malformées et mots de passe surdimensionnés, une méthode qui rappelle celle employée par OpenAI pour débusquer 948 failles dans le noyau Linux.
Quels systèmes sont réellement exposés
L’exploitation suppose la réunion de plusieurs conditions, ce qui limite le périmètre sans le rendre marginal pour autant. Il faut un serveur SSH compilé avec musl, une authentification sans PAM, la connexion par mot de passe activée, au moins un compte verrouillé par « * » et un autre compte disposant d’un mot de passe valide.
- Distributions et environnements concernés : Alpine Linux, OpenWrt, Buildroot et Yocto, très présents dans les conteneurs Docker, les routeurs et les objets connectés.
- Configuration par défaut d’Alpine : le paquet openssh-server n’utilise pas PAM et laisse la connexion par mot de passe active.
- Systèmes épargnés : Debian, Ubuntu, Fedora et les autres distributions fondées sur la glibc, les installations qui passent par PAM, ainsi que le serveur Dropbear et OpenBSD.
Le cas d’Alpine illustre la façon dont les décisions s’additionnent. En 2022, la version 3.16 de la distribution a remplacé le verrou « ! » du compte root par « * » afin de rétablir la connexion par clé, ouvrant sans le savoir la porte à ce contournement. Le chercheur signale aussi que les images officielles d’Alpine pour AWS et Azure créent un compte « alpine » qui peut exécuter des commandes d’administration via doas sans mot de passe, ce qui revient à donner un accès root à quiconque parvient à s’y connecter.
Une erreur vieille de dix ans
Ce défaut n’est pas le fruit d’une ligne de code fautive écrite récemment. Il naît de la rencontre de deux choix raisonnables pris séparément, l’un par musl en 2012, l’autre par OpenSSH en 2016, et il est resté invisible pendant une décennie. À titre de comparaison, la glibc et la bibliothèque libxcrypt adoptée par Debian renvoient des valeurs d’échec différentes, qui ne peuvent pas coïncider avec un compte verrouillé.
Le correctif intervient quelques jours après une autre modification du même code d’OpenSSH, publiée le 30 octobre 2026 pour la gestion des empreintes factices, à quelques lignes seulement de la zone fautive.
Les gestes à faire sur un serveur Alpine
La première mesure consiste à installer OpenSSH 10.6p2, avec la commande apk upgrade openssh sur Alpine. Lorsque la mise à jour ne peut pas être appliquée immédiatement, désactiver la connexion par mot de passe en ajoutant la directive PasswordAuthentication no dans la configuration de sshd, puis en redémarrant le service, ferme la brèche : seules les clés SSH restent alors acceptées.
Les administrateurs peuvent ensuite rechercher des traces d’intrusion. Une ligne « Accepted password » dans le journal /var/log/messages pour un compte censé être verrouillé par « * » dans /etc/shadow constitue un signal d’alerte. Le chercheur a également publié un outil de vérification. Routeurs et boîtiers connectés, souvent construits avec OpenWrt, Buildroot ou Yocto, figurent parmi les cibles régulières des pirates, comme l’a rappelé récemment un botnet de 1,3 million de boîtiers Android TV.
La prochaine étape attendue est l’attribution d’un identifiant CVE et la diffusion du correctif dans les dépôts des distributions concernées.
