Une vuln\u00e9rabilit\u00e9 ancienne permettait de contourner le verrouillage de certains comptes via OpenSSH sur des configurations Linux utilisant musl.<\/strong> La d\u00e9couverte est r\u00e9cente, mais le d\u00e9faut remonte \u00e0 une interaction logicielle pr\u00e9sente depuis 2016. Un correctif est disponible : OpenSSH 10.6p2 a \u00e9t\u00e9 publi\u00e9 le 5 novembre 2026.<\/p>\n Le p\u00e9rim\u00e8tre est essentiel. Le probl\u00e8me concerne des syst\u00e8mes utilisant la biblioth\u00e8que musl, avec PAM d\u00e9sactiv\u00e9 et une authentification par mot de passe accessible dans les conditions d\u00e9crites par le chercheur. Il ne permet pas de conclure que tous les serveurs Linux ou toutes les installations d\u2019OpenSSH sont vuln\u00e9rables. Alpine Linux figure parmi les environnements \u00e0 examiner, mais le nom d\u2019une distribution ne remplace pas la v\u00e9rification de sa configuration.<\/p>\n<\/p>\n Le m\u00e9canisme d\u00e9crit par le chercheur \u00d6zg\u00fcn K\u00fcltekin repose sur une confusion entre une valeur d\u2019erreur et une valeur utilis\u00e9e pour verrouiller un compte. Pour certaines entr\u00e9es de longueur inhabituelle, le calcul assur\u00e9 par musl pouvait renvoyer un ast\u00e9risque. Dans les configurations concern\u00e9es, la comparaison effectu\u00e9e lors de l\u2019authentification pouvait alors accepter ce r\u00e9sultat \u00e0 tort.<\/p>\n Le point important n\u2019est pas l\u2019existence d\u2019un \u00ab mot de passe magique \u00bb. C\u2019est le traitement incorrect d\u2019un \u00e9chec : une valeur qui aurait d\u00fb conduire \u00e0 refuser l\u2019acc\u00e8s pouvait \u00eatre interpr\u00e9t\u00e9e comme une correspondance. L\u2019\u00e9quipe OpenSSH pr\u00e9cise que la cause racine se trouve hors de sshd, tout en fournissant un contournement de s\u00e9curit\u00e9 dans ce dernier, puisque le d\u00e9faut reste exploitable par son interm\u00e9diaire.<\/p>\n Notre lecture : ce cas illustre la difficult\u00e9 de s\u00e9curiser les fronti\u00e8res entre composants. Une biblioth\u00e8que peut renvoyer une valeur particuli\u00e8re, et son appelant lui donner un sens diff\u00e9rent. L\u2019anciennet\u00e9 d\u2019un composant ne prouve ni son invuln\u00e9rabilit\u00e9 ni l\u2019inutilit\u00e9 des protections qu\u2019il offre au quotidien.<\/p>\n<\/p>\n Pour un administrateur, la priorit\u00e9 est de consulter l\u2019avis de s\u00e9curit\u00e9 et les paquets corrig\u00e9s de sa distribution. Un correctif peut \u00eatre r\u00e9troport\u00e9 sans que le num\u00e9ro affich\u00e9 corresponde exactement \u00e0 celui de la derni\u00e8re version amont. Il faut donc v\u00e9rifier l\u2019\u00e9tat du paquet install\u00e9, plut\u00f4t que se fier uniquement \u00e0 une comparaison de num\u00e9ros.<\/p>\n \u00c0 d\u00e9faut de correction imm\u00e9diatement disponible, la d\u00e9sactivation de l\u2019authentification par mot de passe figure parmi les mesures indiqu\u00e9es dans la divulgation. Une modification de l\u2019acc\u00e8s SSH doit \u00eatre pr\u00e9par\u00e9e et v\u00e9rifi\u00e9e en conservant un moyen d\u2019administration fonctionnel, pour \u00e9viter de verrouiller ses propres acc\u00e8s.<\/p>\n Enfin, publier un correctif ne signifie pas que tous les syst\u00e8mes l\u2019ont re\u00e7u. La d\u00e9couverte ne doit \u00eatre pr\u00e9sent\u00e9e ni comme une menace universelle, ni comme une histoire enti\u00e8rement r\u00e9gl\u00e9e pour chaque installation. Ce qui compte est la pr\u00e9sence des conditions vuln\u00e9rables et l\u2019application effective de la correction.<\/p>\n Sources : numerama.com<\/a> \u00b7 openssh.org<\/a> \u00b7 sshhole.com<\/a>.<\/small><\/p>\n<\/p>\nQuand une erreur de calcul ressemble \u00e0 un verrou<\/h2>\n
V\u00e9rifier le correctif de sa distribution<\/h2>\n
Sources<\/h2>\n