Contexte et découverte
Une faille de sécurité importante a été identifiée dans OpenSSH et corrigée en urgence le 5 novembre. Selon le développeur Damien Miller, le correctif a été proposé moins de 24 heures après le signalement. Cette faille permettait d’accéder à distance à des serveurs Alpine Linux sans connaître le mot de passe, à condition d’utiliser un mot de passe aléatoire d’au moins 256 caractères.
Conditions d'exploitation
L’équipe d’OpenSSH recommande de désactiver immédiatement l’authentification par mot de passe, voire le service SSH, tant que le correctif n’est pas appliqué. La plupart des systèmes d’exploitation – Windows, macOS, Debian, Ubuntu, Red Hat, Fedora et les BSD – ne sont pas concernés en configuration par défaut. L’urgence provient du fait que la configuration par défaut d’Alpine Linux correspond exactement aux conditions requises pour exploiter la faille.
Conditions spécifiques à Alpine Linux
Alpine Linux est vulnérable si trois critères sont remplis : le service SSH accepte les mots de passe (activé par défaut), il existe au moins un compte sans mot de passe, et au moins un autre compte possède un mot de passe. Le compte root est fourni sans mot de passe, mais OpenSSH refuse généralement les connexions par mot de passe à ce compte. Cette protection disparaît lorsqu’un autre compte dispose des droits d’élévation, comme c’est le cas dans les images Alpine 8.18.11 à 3.24.3 destinées au cloud. Dans ces circonstances, la simple définition d’un mot de passe sur un compte secondaire ouvre la porte à un accès complet.
Mécanisme de la faille
Les mots de passe ne sont jamais stockés en clair ; seul leur empreinte (hash) est conservée. Pour un compte sans mot de passe, Linux enregistre un astérisque (« ») comme empreinte. Alpine utilise la bibliothèque musl, qui refuse de calculer un hash pour un mot de passe de plus de 256 caractères et renvoie également un astérisque. OpenSSH compare alors les deux astérisques et considère les empreintes identiques, autorisant la connexion. La comparaison nécessite la présence d’un compte avec un vrai mot de passe, d’où la condition mentionnée précédemment. Les distributions n’utilisant pas musl, ou celles qui délèguent l’authentification à PAM, ne sont pas affectées.
Historique et portée
Le comportement de musl date de 2012, tandis que le changement dans OpenSSH remontant à 2016 rend la combinaison exploitable depuis près d’une décennie. Le correctif d’OpenSSH empêche désormais toute comparaison avec une empreinte trop courte pour être valide, mais la cause profonde reste dans musl. Le problème avait déjà été signalé en 2024, la réponse de musl étant jugée inappropriée.
Correctif et actions recommandées
La solution consiste à mettre à jour OpenSSH et les paquets Alpine corrigés. Alpine a publié des correctifs pour toutes les versions depuis 3.16, y compris les versions non maintenues comme 3.21. Les nouvelles versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent la correction. Après mise à jour, il faut redémarrer le service SSH. En l’absence de mise à jour immédiate, il faut désactiver l’authentification par mot de passe et vérifier que l’accès par clé cryptographique fonctionne. Dans les environnements cloud, il faut s’assurer que toutes les machines virtuelles actives sont corrigées, car la reconstruction d’images ne protège pas les instances déjà lancées.
Évaluation du risque
Le NIST attribue à cette vulnérabilité un score CVSS de 8,1, la classant comme « élevée ». Damien Miller, dans son message, la qualifie toutefois de « critique ». Le débat persiste quant au niveau de dangerosité réel.
Source : NEXT
Service
Maintenance et gestion de systèmes informatiques(Web, Mobile & Logiciel)
Service professionnel de gestion, de maintenance et d'optimisation pour vos applications web, mobiles et logiciels existants.
À partir de 55 000 F CFADécouvrir le service
