OpenSSH « sshole » : un mot de passe de 257 caractères ouvre Alpine Linux en root, et c’est déjà exploité

Une faille d’OpenSSH baptisée « sshole » permet de se connecter sans mot de passe valide à des serveurs Alpine Linux et à d’autres systèmes Linux bâtis sur la bibliothèque musl. Corrigée le 5 novembre dans OpenSSH 10.6p2, elle est déjà exploitée : un pot de miel a été compromis en root moins de neuf heures après la publication de la CVE.

La vulnérabilité porte la référence CVE-2026-123158 et un score CVSS de 8,1. Elle a été signalée par Özgün Kültekin, chercheur chez Wakefield. Dans les notes de version d’OpenSSH 10.6p2, l’équipe parle d’un « contournement de l’authentification par mot de passe » touchant certains systèmes Linux compilés et exécutés sans PAM, le module d’authentification standard. Les développeurs estiment que la cause racine se trouve en dehors de sshd, mais ont choisi de la neutraliser de leur côté.

À lire aussi : Voyager en Grèce avec Selectour : comment ça se passe ?

Un astérisque qui vaut mot de passe

Sans PAM, sshd vérifie un mot de passe en le passant à la fonction crypt(), puis compare le résultat au champ stocké dans /etc/shadow. Deux comportements se croisent. D’une part, la fonction crypt() de musl refuse les entrées SHA-256 et SHA-512 de plus de 256 octets et renvoie alors la chaîne « * » en guise d’erreur, au lieu d’une valeur nulle. D’autre part, un compte sans mot de passe, comme un utilisateur qui ne se connecte que par clé, contient justement « * » dans ce champ. Pour ces comptes, sshd emprunte le sel d’un autre compte afin de traiter la tentative.

Résultat : un mot de passe quelconque de 257 à 1 024 octets produit « * », la comparaison réussit et la session s’ouvre. Selon l’analyse publiée par ArmorCode, une seule connexion suffit. Trois conditions doivent être réunies : l’authentification par mot de passe activée (c’est le réglage par défaut d’OpenSSH), un compte sans mot de passe dont l’attaquant connaît le nom, et au moins un autre compte local doté d’un vrai hachage de type $5$ ou $6$. Le bug remonterait à une dizaine d’années.

Alpine Linux est en première ligne, car son paquet openssh-server est compilé exactement de cette façon. Sont concernés le compte root des images de base (atteignable si PermitRootLogin l’autorise, ou via un autre compte disposant de doas), les utilisateurs créés avec adduser sans mot de passe, l’utilisateur alpine des images cloud « tiny-cloud » et les comptes issus d’un annuaire via musl-nscd. Özgün Kültekin cite aussi OpenWrt, Buildroot, Yocto et « beaucoup des images Docker » que les administrateurs ont téléchargées. Les distributions à base de glibc (Debian, Ubuntu, RHEL, Fedora) ne sont pas touchées, pas plus que les serveurs qui passent par PAM ou qui refusent les mots de passe.

Neuf heures entre la CVE et le premier root

La société de veille Previdian a donné l’alerte vendredi. Son fondateur, Ryan Dewhurst, a indiqué à Help Net Security que la première tentative est arrivée moins de neuf heures après la publication de la CVE et qu’un accès root a été confirmé sur un pot de miel tournant sous un vrai Alpine. L’adresse IP en cause, située au Japon, envoyait des mots de passe surdimensionnés puis lançait les commandes id, uname et hostname. D’après SecurityWeek, Previdian comptait ce week-end 20 tentatives venues de 13 adresses dans 9 pays, entre le 6 et le 8 novembre. watchTowr observe de son côté des botnets et des mineurs de cryptomonnaie, et rien de plus ciblé pour l’instant.

Damien Miller, développeur d’OpenSSH, a été plus direct sur Mastodon : les utilisateurs d’un Linux musl sans PAM doivent « arrêter de lire » et passer PasswordAuthentication à no, ou couper SSH, immédiatement.

Alpine a publié des paquets corrigés le jour même pour toutes ses branches, y compris celles qui ne sont plus maintenues depuis la 3.16. Les versions à viser sont 10.6_p2-r0 sur edge, 10.3_p1-r2 sur la 3.24, 10.2_p1-r1 sur la 3.23 et 10.0_p1-r11 sur la 3.22. La mise à jour ne remplace pas le démon en cours d’exécution : il faut redémarrer sshd, sans quoi l’ancien binaire continue d’accepter les connexions.

apk upgrade -U -a
rc-service sshd restart

Pour vérifier une éventuelle intrusion, les journaux d’authentification doivent être fouillés à la recherche de lignes « Accepted password for » sur des comptes qui n’ont pas de mot de passe. Sur ces comptes, une telle ligne n’a aucune raison d’exister.

L’épisode tombe alors que l’équipe d’OpenSSH rappelle, en tête de ses notes de version, recevoir un grand nombre de rapports de sécurité produits ou assistés par des modèles d’IA, et avoir constaté que des bugs trouvés ainsi sont ensuite redécouverts par d’autres chercheurs. Le projet a annoncé qu’il publierait désormais des correctifs plus fréquents plutôt que de les regrouper. Avec sshole, le délai entre le correctif et l’attaque s’est compté en heures.

Sources : OpenSSH, Help Net Security, SecurityWeek, ArmorCode, The Hacker News.

Ajouter Geek Actu à mes sources préférées sur Google