sshole : une faille OpenSSH sur Alpine Linux permet la connexion sans mot de passe

Un mot de passe qui ne devrait jamais fonctionner

Sous Linux, lorsque le champ du mot de passe d'un compte dans le fichier /etc/shadow contient un astérisque (*), l'authentification ordinaire par mot de passe doit être bloquée, bien que d'autres méthodes, comme les clés cryptographiques, restent possibles. Selon Kültekin, le défaut apparaît quand OpenSSH vérifie un mot de passe pour un tel compte. Faute de données, il utilise celles d'un autre compte pour effectuer la vérification.

Si le mot de passe saisi compte entre 257 et 1 024 octets, la fonction de musl qui le traite renvoie un astérisque pour signaler une erreur. Or le compte protégé contient lui aussi un astérisque : le serveur juge les deux valeurs identiques et autorise l'accès.

L'origine est ancienne. En 2012, musl a modifié la façon de signaler certaines erreurs et limité la longueur des mots de passe pour éviter les attaques par déni de service. Quatre ans plus tard, OpenSSH a introduit des changements pour empêcher de deviner les utilisateurs existants en mesurant les temps de réponse. En 2022, Alpine a ajusté la configuration de son compte administrateur pour autoriser l'accès par clés SSH. Ces correctifs répondaient à des problèmes distincts, mais ils ont fini par interagir de manière imprévue.

Qui est concerné

Utiliser Alpine ne rend pas forcément vulnérable. Selon Check Point, plusieurs conditions doivent être réunies : OpenSSH fonctionne sans PAM, accepte les mots de passe et trouve un compte avec l'astérisque. Un autre compte local actif doit en outre posséder un hachage généré en SHA-256 ou SHA-512. Les systèmes sans authentification par mot de passe ou utilisant PAM ne sont pas concernés.

Les conséquences sont graves si le compte compromis dispose de droits élevés. Alpine cite certaines images officielles pour le cloud où l'utilisateur alpine peut exécuter des commandes d'administrateur via doas sans mot de passe. Sûres au premier démarrage, elles peuvent devenir vulnérables si un compte au hachage compatible est configuré ensuite. Des exploitations ont déjà été observées : la société Previdian affirme avoir détecté huit tentatives depuis une même adresse IP et confirmé un accès administrateur sur l'un de ses serveurs leurres.

Comment se protéger

OpenSSH a publié la version 10.6p2 et Alpine a diffusé des mises à jour pour plusieurs branches, dont d'anciennes. Les responsables préviennent qu'installer les correctifs ne suffit pas : il faut redémarrer le service SSH. Ceux qui ne peuvent pas encore mettre à jour doivent désactiver l'authentification par mot de passe et redémarrer le service, après avoir vérifié que l'accès par clés fonctionne.