veilletech.fr
6 nov. Feed du jour
#01 SÉCURITÉ Faille

OpenSSH 10.6p2 : un mot de passe long ouvre Alpine

Sur Alpine, l'étoile qui verrouillait un compte l'ouvrait.

Sur les systèmes musl comme Alpine, un sshd compilé sans PAM accepte n'importe quel mot de passe de 257 à 1 024 octets pour un compte sans mot de passe (« * » dans /etc/shadow), dès qu'un autre compte en a un vrai. OpenSSH 10.6p2 et des paquets Alpine corrigés sont sortis le 5 novembre ; aucune attaque n'est signalée et aucun CVE n'était encore attribué.

4 min de lectureintermédiairevidéo 1:16
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Le mécanisme
  3. Qui est exposé
  4. Comment s'y prendre
  5. Ai-je été visé ?
  6. À retenir

Ce qui se passe

Sur un système bâti sur la bibliothèque C musl (Alpine Linux, mais aussi OpenWrt, Buildroot ou Yocto), un sshd qui vérifie lui-même les mots de passe, sans PAM, accepte n'importe quel mot de passe de 257 à 1 024 octets pour un compte qui n'en a pas : utilisateur réservé aux clés, compte venu d'un annuaire, root. OpenSSH classe la faille critique et a publié OpenSSH 10.6p2 le 5 novembre 2026 ; Alpine a sorti des paquets corrigés pour toutes ses branches jusqu'à la 3.16. Le défaut a été signalé par Özgün Kültekin (Wakefield). Aucune attaque n'était rapportée, et aucun identifiant CVE n'était attribué à la publication.

Le mécanisme

Trois décisions, chacune défendable, se combinent :

  1. Un compte sans mot de passe porte * dans /etc/shadow : aucune empreinte ne peut égaler ce champ.
  2. Depuis juillet 2016, pour corriger CVE-2016-6210 (deviner les comptes existants au temps de réponse), sshd hache quand même la saisie d'un tel compte, avec le sel emprunté à un autre compte qui a une vraie empreinte.
  3. En août 2012, musl a fait renvoyer * à crypt() en cas d'échec, plutôt que NULL que trop de programmes ne testaient pas. Trois semaines plus tard, il a plafonné à 256 octets les mots de passe des empreintes $5$ et $6$, contre le déni de service.

Au-delà de 256 octets, crypt() échoue donc, renvoie *, et * égale le champ stocké. La borne haute, 1 024 octets, est la limite propre à sshd.

ouiMot de passe de 300octetssshd sans PAMChamp shadow : *Sel emprunté à un autrecomptecrypt() de musl : échecValeur renvoyée : ** = * ?Connexion acceptée
Comment un mot de passe trop long finit par égaler le champ d'un compte verrouillé

Qui est exposé

L'avis d'Alpine pose quatre conditions, toutes nécessaires :

L'attaquant doit aussi connaître le nom du compte visé ; l'attaque réussit alors à chaque essai, en une seule connexion. root, livré en root:* depuis Alpine 3.16 environ, reste protégé par PermitRootLogin prohibit-password, sauf si un autre compte exposé peut devenir root. C'est le cas de l'utilisateur alpine des images cloud tiny-cloud de 3.18.11 à 3.24.3, qui dispose de doas sans mot de passe. Ces images sont saines au premier démarrage et deviennent vulnérables dès qu'une empreinte $6$ apparaît, par exemple quand un administrateur pose un mot de passe pour la console.

Ne sont pas touchés : glibc, les systèmes qui passent par PAM, Dropbear (serveur SSH par défaut d'OpenWrt), OpenBSD, les conteneurs qui ne lancent pas sshd, les images configurées par cloud-init (qui écrit PasswordAuthentication no) et les comptes verrouillés par !.

Comment s'y prendre

Terminal
apk upgrade -U -a
rc-service sshd restart   # la mise à jour ne redémarre pas le service

Les versions ponctuelles 3.21.10, 3.22.8, 3.23.8 et 3.24.4 embarquent déjà le paquet corrigé, et les branches 3.16 à 3.21, hors support, en ont reçu un aussi. Si vous compilez OpenSSH, passez en 10.6p2 : il refuse toute correspondance quand le champ stocké fait moins de quatre caractères. OpenSSH parle d'un contournement, la cause étant hors de sshd.

Si la mise à jour doit attendre, coupez les mots de passe, après avoir vérifié qu'une connexion par clé fonctionne et en gardant votre session ouverte jusqu'à une nouvelle connexion réussie :

Terminal
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication   # attendu : passwordauthentication no

La configuration d'Alpine lit sshd_config.d à partir de la 3.19. Passez aussi à no chaque ligne PasswordAuthentication de /etc/ssh/sshd_config, blocs Match compris.

Ai-je été visé ?

Cherchez dans /var/log/messages des lignes Accepted password for sur un compte sans mot de passe (alpine, root, un compte à clés). Sur une machine exposée, relisez aussi l'usage de doas, les comptes créés récemment, les fichiers et les authorized_keys. L'avis est net : si vous ne pouvez pas exclure une connexion, traitez la machine comme compromise. Le chercheur propose un outil de vérification sur github.com/oz9un/sshole.

Damien Miller, pour OpenSSH, justifie la publication sans embargo prolongé : l'équipe voit désormais des agents d'IA retrouver les mêmes bugs, parfois en quelques heures.

Source : The Hacker News, qui cite l'avis Alpine et les notes de version d'OpenSSH. Récit technique du chercheur sur sshhole.com. Sources en anglais.