blacksloth.fr

OpenSSH : la faille « sshole » contourne le mot de passe sur Alpine et les systèmes musl

Le 5 novembre 2026, le projet OpenSSH a publié la version 10.6p2 pour corriger un contournement de l’authentification par mot de passe. La faille, surnommée « sshole » et référencée CVE-2026-123158, ne touche pas tous les serveurs SSH : elle exige un Linux construit avec la bibliothèque C musl, comme Alpine, et sans PAM. Elle est exploitée : la CISA l’a ajoutée le 9 novembre à son catalogue des vulnérabilités exploitées.

Ce que dit le correctif

Les notes de version d’OpenSSH 10.6p2 parlent d’un « critical security workaround » (contournement de sécurité critique, traduit par nos soins) pour les systèmes Linux qui utilisent musl avec PAM désactivé. PAM signifie « Pluggable Authentication Modules » (CSO). Les mainteneurs écrivent aussi que, selon eux, la cause racine du bug se situe « en dehors de sshd », tout en précisant qu’il est exploitable via sshd et peut y être évité. La faille a été signalée par Özgün Kültekin, de la société Wakefield.

Le suivi de sécurité Debian reprend la description du CVE : sshd avant 10.6p2, sous Linux, quand musl est utilisée sans PAM, accepte pour certaines configurations de comptes « any password between 256 and 1024 characters ». Autrement dit, un mot de passe de 256 à 1 024 caractères suffit, dans certaines configurations de comptes.

Le mécanisme : une étoile qui veut dire deux choses

Selon CSO Online, la faille tient à l’empilement de trois changements indépendants. En 2012, musl a plafonné la longueur des mots de passe à 256 octets, et sa fonction de hachage a commencé à renvoyer un astérisque (« * ») en cas d’échec. Or, sous Unix, cet astérisque dans le champ du mot de passe d’un compte signifie que la connexion par mot de passe est désactivée.

En 2016, OpenSSH a modifié sa vérification pour les comptes sans sel (la valeur aléatoire mêlée au hachage) : il emprunte celui d’un autre compte, afin de gêner la devinette de noms d’utilisateur. En 2022, Alpine a mis un astérisque dans le champ du mot de passe de root pour que la connexion par clé SSH continue de fonctionner.

Conséquence, toujours d’après CSO : avec un mot de passe trop long, le hachage échoue et renvoie « * ». sshd compare ce résultat à l’astérisque stocké pour le compte, constate l’égalité et accepte la connexion. Nous ne détaillons pas la manipulation exacte.

Qui est exposé, qui ne l’est pas

CSO énumère les conditions cumulatives : une distribution musl, OpenSSH (et non une alternative comme Dropbear), une compilation sans PAM, l’authentification par mot de passe activée, et le nom d’un compte dont le mot de passe est désactivé. Selon CSO, il faut aussi qu’un autre compte dispose d’un vrai mot de passe, ce qui s’accorde avec l’emprunt du sel décrit par CSO.

Toujours selon cet article, la configuration par défaut d’Alpine réunit les conditions de compilation (sans PAM, mot de passe activé), mais l’attaque exige en plus qu’un autre compte ait un vrai mot de passe. Sur les images cloud officielles d’Alpine, de la 3.18.11 à la 3.24.3, l’utilisateur « alpine » disposerait de droits doas sans mot de passe, ce qui permettrait de passer root. C’est une affirmation de CSO, que nous n’avons pas retrouvée dans les pages d’Alpine.

Red Hat indique dans son avis que ses produits ne sont « pas affectés » : ils lient OpenSSH à la bibliothèque GNU (glibc) et activent PAM par défaut. Le suivi Debian affiche pourtant les versions bookworm et trixie comme « Vulnerable ». CSO écrit de son côté que Debian, Ubuntu et Fedora ne sont pas touchées. La page Debian n’explique pas cet écart apparent et nous ne le tranchons pas. Le plus sûr est de vérifier sa propre installation.

Côté correctifs, le suivi de sécurité d’Alpine liste une version corrigée par branche : 10.6_p2-r0 pour edge, 10.3_p1-r2 pour la 3.24, 10.2_p1-r1 pour la 3.23, 10.0_p1-r11 pour la 3.22, et ainsi de suite jusqu’à la 3.19. Debian indique 1:10.6p2-1 en forky et sid.

Exploitée, oui ; massive, rien ne le montre

La CISA a inscrit la faille à son catalogue KEV le 9 novembre 2026, sous l’intitulé « OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability ». Elle a fixé au 12 novembre la date limite et demandé un tri forensique.

Le tableau de bord de GreyNoise, consulté le 11 novembre 2026, donne la chronologie : correctif publié le 5 novembre à 09 h 01 UTC, premier exploit public sur GitHub à 13 h 16, première exploitation réussie observée par GreyNoise le 7 novembre à 00 h 46 UTC. L’entreprise compte 33 chaînes de post-exploitation confirmées, depuis 9 adresses IP. Ce sont des données de télémétrie issues de son propre réseau de capteurs, pas un recensement global.

GreyNoise précise aussi que l’analyse de l’implant « TAC Agent » est produite par un modèle de langage. Le rattachement à un ensemble d’activités (cluster) que GreyNoise nomme « GT10 » est de confiance haute pour les intrusions observées directement, moyenne pour les artefacts issus du serveur de l’adversaire. L’entreprise ajoute que « toute l’activité SSHole n’est pas attribuable à GT10 » (traduit par nos soins). Rien dans les sources que nous avons pu lire ne permet de parler d’exploitation massive.

Pourquoi les scores ne concordent pas

Red Hat affiche un CVSS 3.1 de 9,8, qu’il dit « préliminaire », contre 8,1 chez cve.org. Les deux vecteurs ne diffèrent que sur la complexité de l’attaque : faible (AC:L) pour Red Hat, élevée (AC:H) pour cve.org. GreyNoise indique que la fiche a été publiée dans la NVD avec 8,1, et le projet OpenSSH parle d’un contournement de sécurité « critique ». Nous n’avons pas pu lire la page de la NVD ; ce point repose donc sur le tableau de bord de GreyNoise. L’écart traduit un désaccord de notation : la condition « musl sans PAM » rend-elle l’attaque difficile, ou seulement spécifique ?

Qui est responsable : le débat

Les mainteneurs d’OpenSSH situent la cause hors de sshd. Un billet de blog (non signé, du 6 novembre) pousse cette thèse : selon lui, la faute incombe davantage à musl, qui renvoie « * » là où POSIX prévoit NULL. Il rapporte que Rich Felker, mainteneur de musl, ne voit pas là une vulnérabilité de musl et reproche à OpenSSH de se fier au résultat d’une comparaison faite avec le hachage d’un autre utilisateur. Le même billet note que les distributions qui compilent sshd sans PAM partagent la responsabilité. Il s’agit d’opinions, pas de faits établis.

Que faire

  • Sur Alpine ou toute distribution musl : passer à OpenSSH 10.6p2 ou au paquet corrigé de sa branche.
  • En attendant, après s’être assuré qu’une connexion par clé fonctionne (pour ne pas s’enfermer dehors), désactiver l’authentification par mot de passe (option PasswordAuthentication de sshd_config, activée par défaut), la parade citée par CSO.

Reste à savoir combien de machines musl exposent SSH avec mot de passe sur Internet : aucune source lue ne donne de chiffre fiable.

Sources

In

, , , , ,
Enable Notifications OK No thanks