Cybersécurité

OpenSSH 10.6p2 : un mot de passe trop long ouvre la porte des Linux embarqués

6 novembre 2026 Alexandre FAUVEL 4 min de lecture Actualité 1 vue

D’habitude, on reproche aux utilisateurs des mots de passe trop courts. Cette fois, c’est un mot de passe trop long qui ouvre la porte. Le 5 novembre 2026, le CERT-FR a publié une alerte (CERTFR-2026-ALE-015) sur OpenSSH, le serveur SSH présent sur une immense partie des systèmes Linux. Dans une configuration précise, l’authentification peut être contournée, et le CERT-FR qualifie l’exploitation de « triviale ». La configuration en question est justement celle de nombreux systèmes embarqués.

Le mécanisme, en clair

Le problème ne vient pas vraiment d’OpenSSH, mais de musl, une bibliothèque C légère très utilisée dans l’embarqué. Quand on lui demande de chiffrer un mot de passe de plus de 256 caractères, elle refuse… et renvoie le caractère « * ». Or « * », c’est précisément ce qu’on trouve dans le fichier /etc/shadow pour les comptes sans mot de passe : comptes réservés aux clés SSH, comptes d’annuaire, ou le compte root par défaut sur Alpine. La comparaison tombe juste, et la porte s’ouvre.

Toutes ces conditions doivent être réunies :

sshd compilé avec musl (et non glibc) ;
PAM non utilisé (c’est le cas par défaut sur Alpine, ou avec UsePAM no) ;
authentification par mot de passe active (le réglage par défaut) ;
un compte dont le mot de passe est « * ».

Les distributions classiques basées sur glibc (Debian, Ubuntu, Fedora) ne sont pas concernées, pas plus que les équipements qui utilisent Dropbear au lieu d’OpenSSH. Le correctif est arrivé avec OpenSSH 10.6p2, publié le 5 novembre.

Où se cache musl dans nos installations ?

C’est là que l’alerte me parle. Le chercheur à l’origine de la découverte cite Alpine Linux (y compris ses images cloud), OpenWrt, Buildroot et Yocto, ainsi que les nombreuses images Docker construites sur Alpine. Traduction pour un intégrateur :

les conteneurs Docker qui tournent sur vos serveurs ou vos NAS : outils de supervision, passerelles MQTT, petits services maison ;
les routeurs et passerelles basés sur OpenWrt, très présents dans les routeurs 4G de secours et certaines passerelles industrielles ;
les boîtiers construits avec Buildroot ou Yocto : passerelles IoT, contrôleurs, boîtiers de terrain.

Attention, je ne dis pas que tous ces équipements sont vulnérables. Beaucoup de produits construits avec Buildroot ou Yocto utilisent glibc, et nombre d’équipements embarqués préfèrent Dropbear à OpenSSH. Mais impossible de le savoir sans demander : c’est au constructeur de répondre noir sur blanc.

Ce que je ferais dès maintenant

Désactiver l’authentification SSH par mot de passe partout où c’est possible (PasswordAuthentication no) et passer aux clés. C’est la mesure de contournement recommandée par le CERT-FR, et elle aurait dû être la règle depuis longtemps.
Mettre à jour OpenSSH sur les systèmes Alpine (apk upgrade openssh) et reconstruire les images Docker : mettre à jour l’hôte ne corrige pas ce qui tourne dans le conteneur.
Interroger les constructeurs de vos passerelles, routeurs 4G et boîtiers embarqués : musl ou glibc, OpenSSH ou Dropbear, et quelle date de correctif.
Ne jamais exposer SSH sur Internet. L’administration passe par un VPN et un réseau dédié, filtré par le pare-feu.
Chercher des traces. Le CERT-FR relaie une méthode du chercheur : repérer dans les journaux des connexions réussies sur des comptes qui n’ont pas de mot de passe. Une connexion par mot de passe sur un compte censé n’accepter que des clés, c’est un signal d’alarme.

Mon avis

Ce qui me frappe, c’est qu’aucun des deux composants n’est « bogué » au sens strict : musl applique une limite pour se protéger, OpenSSH compare des empreintes. C’est leur rencontre qui crée la faille, et ce genre de défaut est le plus difficile à anticiper. Quand on évoque le Linux caché dans nos NVR et passerelles, c’est exactement de ça qu’on parle. Pour moi, la leçon tient en une phrase à mettre dans tous les CCTP : l’équipement doit permettre de désactiver l’authentification SSH par mot de passe, et le constructeur doit publier la nomenclature logicielle (SBOM) et ses correctifs. Le Cyber Resilience Act va d’ailleurs dans ce sens.

Sources

Commentaires

Aucun commentaire pour l'instant : lancez la discussion.