Faille OpenSSH sur Alpine Linux : des comptes protégés peuvent devenir accessibles

PUBLICITE

FORMER VOUS GRATUITEMENT GRACE A NOS PARTENAIRES

Une vulnérabilité critique affecte certaines installations OpenSSH utilisant la bibliothèque musl, notamment sur Alpine Linux. Dans une configuration précise, un attaquant connaissant un nom d’utilisateur peut parvenir à ouvrir une session sur un compte qui devait accepter uniquement une clé SSH.

Quels systèmes sont concernés ?

Le risque concerne principalement Alpine Linux ainsi que certaines configurations reposant sur musl, comme Buildroot ou Yocto. OpenWrt utilise généralement Dropbear et n’est concerné que si OpenSSH a été installé manuellement.

  • l’authentification par mot de passe est encore active ;
  • PAM n’est pas utilisé ;
  • un compte est configuré sans mot de passe utilisable ;
  • un autre compte local possède un mot de passe classique.

Pourquoi la faille existe

Le problème vient d’une interaction entre la vérification réalisée par OpenSSH et la manière dont musl signale l’échec du calcul d’un mot de passe anormalement long. Dans les conditions vulnérables, la valeur d’erreur peut être interprétée comme une correspondance valide pour un compte désactivé.

Un risque d’accès administrateur

Certaines images cloud Alpine comportent un utilisateur capable d’obtenir des privilèges élevés sans saisir de nouveau mot de passe. Si ce compte est exposé, une simple connexion initiale pourrait donc déboucher sur une prise de contrôle complète du serveur.

Correctif et mesures immédiates

OpenSSH 10.6p2 corrige le problème. Alpine a également publié des paquets corrigés pour plusieurs versions, y compris certaines branches anciennes. Après la mise à jour, le service SSH doit être redémarré pour charger le nouveau binaire.

  1. installer les mises à jour OpenSSH disponibles ;
  2. désactiver les connexions SSH par mot de passe lorsqu’elles ne sont pas nécessaires ;
  3. vérifier les journaux de connexion ;
  4. examiner les comptes créés et les clés autorisées ;
  5. traiter le serveur comme compromis si une connexion suspecte ne peut pas être exclue.

Sources

0 commentaires pour cet article

Soyez le premier à commenter cet article !

Votre adresse email ne sera pas publiée.

0 commentaire