Contexte et portée
Une vulnérabilité vieille de plus d'une décennie affecte les systèmes exécutant certaines configurations d'Alpine Linux. Cette distribution utilise musl, une implémentation légère de la bibliothèque C, au lieu de la glibc traditionnelle. Le problème apparaît uniquement lorsque OpenSSH est compilé contre musl et que le module d'authentification PAM est désactivé. D’autres distributions pourraient être concernées si elles reproduisent exactement cette pile logicielle, mais aucune preuve publique n’a encore confirmé une propagation au‑delà d’Alpine.
Mécanisme de la vulnérabilité
OpenSSH délègue la vérification du mot de passe à la bibliothèque C. Sous musl, l’absence de PAM empêche le serveur SSH de récupérer correctement le « salt » associé à l’empreinte du mot de passe stockée dans /etc/shadow. Lorsque le champ du mot de passe dans /etc/shadow contient le caractère « * », le compte est considéré comme passwordless. Dans ce cas, OpenSSH accepte toute chaîne de caractères supérieure à 256 octets comme mot de passe valide, contournant ainsi la vérification cryptographique. Le serveur ne réalise aucune seconde tentative, ce qui rend l’exploitation fiable à chaque connexion.
Conditions d’exploitation et impact
Deux prérequis sont indispensables : (1) le système doit disposer d’au moins un compte dont le mot de passe est haché avec SHA‑256 ou SHA‑512, et (2) un autre compte doit être marqué « * » dans /etc/shadow. La présence d’un hachage SHA‑256/512 fournit le « salt » que l’attaquant exploite ; sans ce sel, l’attaque échoue, comme l’a confirmé la société de sécurité Checkpoint. L’attaquant n’a besoin que d’une connexion TCP vers le port SSH ; aucune étape de rebond ou de force brute n’est requise. Une fois connecté à un compte sans mot de passe, il peut exécuter des commandes avec les privilèges de ce compte. Si le compte possède des droits doas ou sudo, l’accès root devient possible. Les comptes root restent protégés tant que la directive PermitRootLogin prohibit‑password est conservée, mais la chaîne de confiance est affaiblie par la présence de comptes intermédiaires privilégiés.
Mitigation et limites
Les mainteneurs d’Alpine recommandent de désactiver la configuration incriminée : activer PAM pour OpenSSH ou recompiler OpenSSH contre glibc. Alternativement, il faut éviter les comptes « * » dans /etc/shadow et privilégier les clés publiques ou les mots de passe forts. La mise à jour des paquets OpenSSH et musl vers des versions qui corrigent l’interaction interne est également conseillée, bien que le correctif exact ne soit pas encore publié. Enfin, la surveillance du trafic SSH et la restriction d’accès au port 22 via des listes blanches réduisent la surface d’exposition. En l’absence de ces mesures, tout service exposé sur Internet reste vulnérable à une prise de contrôle instantanée.
