Eh bien, c'est mauvais

7/10

IAThe PrimeTime6 novembre 2026 à 01:1112:29

Lecteur audio

INTRO

Une faille récemment divulguée dans OpenSSH peut permettre des connexions root non authentifiées sur des systèmes exécutant Alpine Linux, OpenWrt ou d’autres environnements basés sur musl, lorsque SSHD est exposé, que l’authentification par mot de passe est activée et que PAM est désactivé.

POINTS CLÉS

Qui est concerné

Le problème n’affecte pas tous les systèmes Linux, mais il est grave pour un schéma de déploiement courant: les conteneurs légers et les appliances basés sur Alpine ou d’autres distributions musl. Les systèmes sont exposés lorsque sshd est accessible via le réseau, que l’authentification par mot de passe est activée et que PAM n’est pas utilisé. Cette combinaison est fréquente dans les images minimales et les configurations embarquées.

Ce que la faille permet

Dans la configuration vulnérable, un attaquant peut tenter de se connecter en tant que root et fournir un mot de passe de plus de 256 caractères. Si les conditions sont réunies, la connexion réussit sans connaître le vrai mot de passe. En pratique, cela donne un accès administratif distant complet sans point d’appui préalable.

Comment la faille est apparue

Le bug résulte de l’interaction inattendue entre plusieurs anciens correctifs de compatibilité et de sécurité. Les systèmes Unix traditionnels utilisaient des marqueurs spéciaux comme * pour indiquer qu’un compte ne devait pas accepter de connexions. Par ailleurs, le code de hachage des mots de passe a été modifié plus tard afin que des entrées trop longues produisent elles aussi *, au lieu d’échouer autrement.

Pourquoi la longueur du mot de passe compte

Le hachage des mots de passe est coûteux en calcul, et des entrées très volumineuses peuvent créer des risques de déni de service en consommant trop de CPU. Pour limiter cela, le comportement sous-jacent de crypt dans les environnements affectés renvoie * lorsqu’un mot de passe fourni dépasse 256 caractères. Pris isolément, cela devait constituer un rejet sûr.

L’interaction avec OpenSSH

OpenSSH inclut une gestion distincte de l’authentification lorsque PAM n’est pas disponible. Des travaux de durcissement antérieurs ont ajouté une logique simulant des temps de réponse réalistes pour les comptes inexistants ou bloqués afin d’empêcher l’énumération des noms d’utilisateur. Des changements ultérieurs ont aussi représenté l’état du mot de passe root par * dans certains cas sans PAM, en supposant qu’aucun hachage valide ne pourrait jamais entrer en collision avec cette valeur.

Pourquoi la connexion root peut réussir

Dans le chemin vulnérable, sshd traite un mot de passe long pour root, appelle la fonction de hachage et reçoit * parce que le mot de passe dépasse 256 caractères. Il compare ensuite ce résultat à la valeur stockée pour le mot de passe root bloqué, qui est elle aussi *. La comparaison de chaînes correspond, et l’attaquant est authentifié en tant que root.

Pourquoi cette faille se démarque

Beaucoup de failles d’infrastructure médiatisées récemment exigeaient une exploitation complexe ou un long délai avant un impact visible. Celle-ci se distingue parce que le chemin d’exploitation est simple une fois l’environnement correctement identifié. Les mécanismes sous-jacents sont complexes, mais l’attaque elle-même peut se résumer à essayer root avec un mot de passe de 257 caractères.

Découverte et importance

Le chercheur en sécurité Oskars a identifié la faille après des tests automatisés à grande échelle impliquant environ 17,000 tentatives de connexion inhabituelles. Cette découverte montre comment des régressions de sécurité peuvent émerger de correctifs individuellement raisonnables étalés sur de nombreuses années. Elle souligne aussi les risques des conteneurs minimaux et des appliances qui omettent PAM tout en laissant l’accès SSH par mot de passe activé.

Ce que les administrateurs doivent faire

Les équipes utilisant Alpine, OpenWrt ou d’autres systèmes basés sur musl doivent vérifier en urgence si SSHD est exposé à Internet et si l’authentification par mot de passe est activée. Les mesures immédiates incluent la désactivation des connexions par mot de passe, la désactivation de la connexion directe root, la restriction de l’accès SSH aux réseaux de confiance, ou le passage à l’authentification par clé jusqu’à l’installation des paquets corrigés.

CONCLUSION

Cette faille montre comment une chaîne d’anciens choix de conception et de correctifs défensifs peut aboutir à un contournement critique de l’authentification. Pour les systèmes affectés, le risque est immédiat, car une exploitation réussie peut donner à des attaquants distants un contrôle root complet en une seule tentative de connexion.

Poser une question

Sur le même sujet : IA