🚨 Une vulnérabilité vieille de 10 ans : saisir un mot de passe de 257 à 1024 octets suffit pour se connecter au serveur de quelqu’un d’autre
Groupe : 邀请您加入我的群组 悟空粉丝群
Le 5 novembre, OpenSSH et Alpine Linux ont publié un correctif. Le lendemain, Changpeng Zhao a rappelé aux administrateurs sur X : « Cette vulnérabilité d’OpenSSH sur Alpine Linux existe depuis 10 ans. Si vous n’avez pas installé le correctif, faites-le vite. »
Il a également précisé que cela ne signifie pas que Binance a été compromise par cette vulnérabilité.
📊 La chaîne technique mérite davantage d’attention : des chercheurs ont découvert que, dans musl libc, utilisée par Alpine, la fonction de hachage renvoie un astérisque lorsque le mot de passe dépasse la limite de 256 octets ; de son côté, lorsqu’OpenSSH vérifie un « compte sans mot de passe », il peut emprunter le sel d’un autre compte local.
Pris séparément, ces deux comportements sont raisonnables. Mais combinés, ils posent problème : l’astérisque renvoyé correspond exactement à celui qui représente un « champ de mot de passe vide ». Une seule connexion suffit alors pour s’authentifier, sans avoir à essayer plusieurs mots de passe.
🔸 Les conditions ne sont ni très restrictives, ni très courantes : il faut exécuter OpenSSH sans avoir activé PAM, avoir laissé l’authentification par mot de passe activée, connaître le nom d’utilisateur dont le champ de mot de passe contient un astérisque, et avoir aussi sur la machine un autre compte utilisant un hachage SHA-256 ou SHA-512. Les systèmes utilisant PAM, ceux où la connexion par mot de passe est désactivée et ceux qui n’exécutent pas SSH dans leurs conteneurs ne sont pas concernés.
💡 Ce qui mérite vraiment l’attention, ce n’est pas qu’« une nouvelle vulnérabilité a été découverte », mais sa cause : aucune ligne de code isolée n’est fautive ; ce sont les comportements par défaut, raisonnables individuellement, de deux composants qui se sont combinés à la frontière de leurs fonctionnalités. La limite de musl découle de modifications apportées entre 2012 et 2016 ; l’emprunt du sel par OpenSSH a été ajouté en juillet 2016 pour corriger un autre problème. Les deux correctifs étaient justifiés, mais leur combinaison a permis de contourner l’authentification.
⚠️ Le problème ne se limite pas à Alpine : d’autres distributions utilisant musl libc, notamment certaines configurations d’OpenWrt, de Buildroot et de Yocto, sont concernées. OpenWrt utilise Dropbear par défaut et n’est donc pas touché.
📌 Si vous exploitez un nœud, un validateur ou un service auto-hébergé, il vous suffit cette semaine de vérifier une chose : OpenSSH sur votre serveur est bien la version corrigée.
Qui s’occupe des correctifs sur votre serveur ?
Cliquez sur l’avatar pour regarder le direct + rejoignez mon groupe de fans pour recevoir des stratégies quotidiennes 🚀
#公链 #DeFi
Groupe : 邀请您加入我的群组 悟空粉丝群
Le 5 novembre, OpenSSH et Alpine Linux ont publié un correctif. Le lendemain, Changpeng Zhao a rappelé aux administrateurs sur X : « Cette vulnérabilité d’OpenSSH sur Alpine Linux existe depuis 10 ans. Si vous n’avez pas installé le correctif, faites-le vite. »
Il a également précisé que cela ne signifie pas que Binance a été compromise par cette vulnérabilité.
📊 La chaîne technique mérite davantage d’attention : des chercheurs ont découvert que, dans musl libc, utilisée par Alpine, la fonction de hachage renvoie un astérisque lorsque le mot de passe dépasse la limite de 256 octets ; de son côté, lorsqu’OpenSSH vérifie un « compte sans mot de passe », il peut emprunter le sel d’un autre compte local.
Pris séparément, ces deux comportements sont raisonnables. Mais combinés, ils posent problème : l’astérisque renvoyé correspond exactement à celui qui représente un « champ de mot de passe vide ». Une seule connexion suffit alors pour s’authentifier, sans avoir à essayer plusieurs mots de passe.
🔸 Les conditions ne sont ni très restrictives, ni très courantes : il faut exécuter OpenSSH sans avoir activé PAM, avoir laissé l’authentification par mot de passe activée, connaître le nom d’utilisateur dont le champ de mot de passe contient un astérisque, et avoir aussi sur la machine un autre compte utilisant un hachage SHA-256 ou SHA-512. Les systèmes utilisant PAM, ceux où la connexion par mot de passe est désactivée et ceux qui n’exécutent pas SSH dans leurs conteneurs ne sont pas concernés.
💡 Ce qui mérite vraiment l’attention, ce n’est pas qu’« une nouvelle vulnérabilité a été découverte », mais sa cause : aucune ligne de code isolée n’est fautive ; ce sont les comportements par défaut, raisonnables individuellement, de deux composants qui se sont combinés à la frontière de leurs fonctionnalités. La limite de musl découle de modifications apportées entre 2012 et 2016 ; l’emprunt du sel par OpenSSH a été ajouté en juillet 2016 pour corriger un autre problème. Les deux correctifs étaient justifiés, mais leur combinaison a permis de contourner l’authentification.
⚠️ Le problème ne se limite pas à Alpine : d’autres distributions utilisant musl libc, notamment certaines configurations d’OpenWrt, de Buildroot et de Yocto, sont concernées. OpenWrt utilise Dropbear par défaut et n’est donc pas touché.
📌 Si vous exploitez un nœud, un validateur ou un service auto-hébergé, il vous suffit cette semaine de vérifier une chose : OpenSSH sur votre serveur est bien la version corrigée.
Qui s’occupe des correctifs sur votre serveur ?
Cliquez sur l’avatar pour regarder le direct + rejoignez mon groupe de fans pour recevoir des stratégies quotidiennes 🚀
#公链 #DeFi
