OpenSSH et musl : comprendre la faille et son correctif

8 novembre 2026 0 Par eternos974

Une vulnérabilité ancienne permettait de contourner le verrouillage de certains comptes via OpenSSH sur des configurations Linux utilisant musl. La découverte est récente, mais le défaut remonte à une interaction logicielle présente depuis 2016. Un correctif est disponible : OpenSSH 10.6p2 a été publié le 5 novembre 2026.

Le périmètre est essentiel. Le problème concerne des systèmes utilisant la bibliothèque musl, avec PAM désactivé et une authentification par mot de passe accessible dans les conditions décrites par le chercheur. Il ne permet pas de conclure que tous les serveurs Linux ou toutes les installations d’OpenSSH sont vulnérables. Alpine Linux figure parmi les environnements à examiner, mais le nom d’une distribution ne remplace pas la vérification de sa configuration.

Quand une erreur de calcul ressemble à un verrou

Le mécanisme décrit par le chercheur Özgün Kültekin repose sur une confusion entre une valeur d’erreur et une valeur utilisée pour verrouiller un compte. Pour certaines entrées de longueur inhabituelle, le calcul assuré par musl pouvait renvoyer un astérisque. Dans les configurations concernées, la comparaison effectuée lors de l’authentification pouvait alors accepter ce résultat à tort.

Le point important n’est pas l’existence d’un « mot de passe magique ». C’est le traitement incorrect d’un échec : une valeur qui aurait dû conduire à refuser l’accès pouvait être interprétée comme une correspondance. L’équipe OpenSSH précise que la cause racine se trouve hors de sshd, tout en fournissant un contournement de sécurité dans ce dernier, puisque le défaut reste exploitable par son intermédiaire.

Notre lecture : ce cas illustre la difficulté de sécuriser les frontières entre composants. Une bibliothèque peut renvoyer une valeur particulière, et son appelant lui donner un sens différent. L’ancienneté d’un composant ne prouve ni son invulnérabilité ni l’inutilité des protections qu’il offre au quotidien.

Vérifier le correctif de sa distribution

Pour un administrateur, la priorité est de consulter l’avis de sécurité et les paquets corrigés de sa distribution. Un correctif peut être rétroporté sans que le numéro affiché corresponde exactement à celui de la dernière version amont. Il faut donc vérifier l’état du paquet installé, plutôt que se fier uniquement à une comparaison de numéros.

À défaut de correction immédiatement disponible, la désactivation de l’authentification par mot de passe figure parmi les mesures indiquées dans la divulgation. Une modification de l’accès SSH doit être préparée et vérifiée en conservant un moyen d’administration fonctionnel, pour éviter de verrouiller ses propres accès.

Enfin, publier un correctif ne signifie pas que tous les systèmes l’ont reçu. La découverte ne doit être présentée ni comme une menace universelle, ni comme une histoire entièrement réglée pour chaque installation. Ce qui compte est la présence des conditions vulnérables et l’application effective de la correction.

Sources : numerama.com · openssh.org · sshhole.com.