Selon les principes fondamentaux de sécurité, un compte verrouillé par le système d’exploitation ne doit permettre aucune connexion. Toute saisie de mot de passe devrait être immédiatement rejetée. Pourtant, le 5 novembre 2026, un bulletin de sécurité publié par la distribution légère Alpine Linux est venu bousculer cette certitude.
Il suffisait à un attaquant de soumettre un mot de passe de plus de 256 octets pour que le compte administrateur verrouillé lui ouvre l’accès. Le processus n’a nécessité aucune corruption de mémoire ni attaque par force brute sur les hachages. Le système de défense a comparé le mot de passe fourni avec l’indicateur de verrouillage et a validé l’accès de son propre chef.
Cette anomalie découle de la collision fortuite entre trois mécanismes de défense distincts. Lorsqu’un signal d’erreur indiquant un échec de calcul et un statut de compte interdisant l’accès partagent le même symbole, toute la logique d’authentification s’effondre à leur intersection.
Trois défenses coordonnées neutralisées par 257 caractères
Dans le fichier Unix /etc/shadow, l’astérisque * signale des comptes verrouillés depuis des décennies. Lorsque le champ de mot de passe ne contient qu’un astérisque, le système considère l’authentification par mot de passe comme désactivée. Un hachage valide comportant plusieurs dizaines de caractères, une correspondance avec un astérisque unique est théoriquement impossible.
Pour contrer les attaques par canal auxiliaire visant à énumérer les comptes valides par analyse de temps de réponse, les développeurs d’OpenSSH ont intégré un mécanisme dédié. Lorsqu’un compte ne possède pas de mot de passe valide, le service ne renvoie pas d’erreur prématurée. Il emprunte le sel d’un autre compte légitime du système et effectue un calcul de hachage fictif d’une durée équivalente. Le temps de réponse reste ainsi identique, que le compte existe ou non.
De son côté, la bibliothèque C légère musl impose ses propres barrières. Pour éviter que des chaînes arbitraires n’épuisent la mémoire, sa fonction crypt() définit une limite stricte de longueur. Dès qu’un mot de passe dépasse 256 octets, la fonction interrompt le calcul et renvoie un pointeur vers un astérisque statique * en guise de code d’erreur.
Considérés isolément, ces trois mécanismes reflètent des principes d’ingénierie rigoureux. Mais lorsqu’ils se sont rejoints au sein du même système, ils ont involontairement formé un vecteur d’attaque direct.
L’attaquant n’avait besoin que de quatre conditions préalables :
- Pouvoir joindre le port SSH de la machine cible ;
- Trouver un compte dont le champ de mot de passe dans shadow est
*(comme le compte root par défaut d’Alpine depuis la version 3.16) ; - Disposer d’au moins un autre compte légitime avec un hachage au format
$5$ou$6$; - Transmettre un mot de passe d’une taille comprise entre 257 et 1024 octets.
Une fois ces quatre éléments réunis, OpenSSH prend le mot de passe surdimensionné et lance le calcul fictif avec le sel emprunté. La bibliothèque musl interrompt l’opération en raison du dépassement de taille et renvoie le marqueur d’erreur *. OpenSSH compare ensuite cette valeur de retour avec le champ du fichier shadow : les deux côtés présentant un astérisque identique, l’égalité est validée et l’accès est accordé.
Figure : Bulletin de sécurité officiel d’Alpine Linux annonçant le contournement d’authentification sans PAM. Source : alpinelinux.org.
Un astérisque à double sens : Verrou de compte et indicateur d’erreur
Le cœur du problème réside dans un conflit sémantique où différentes couches logicielles ont attribué deux significations opposées à un même caractère. La couche applicative considérait l’astérisque comme un verrou inviolable, tandis que la bibliothèque système le renvoyait comme signal de défaillance.
Dans les implémentations Unix traditionnelles, les fonctions de chiffrement renvoyaient habituellement un pointeur nul en cas d’entrée invalide. L’appelant vérifiait simplement la nullité pour distinguer le succès de l’échec. Néanmoins, les pointeurs nuls provoquaient souvent des plantages par déréférencement dans d’anciens programmes. musl a donc choisi de respecter une norme prescrivant de renvoyer un pointeur vers une chaîne statique * lors d’une erreur.
Cette conception supposait que l’appelant traiterait l’astérisque comme un hachage invalide. Dans un contexte classique, cette hypothèse tenait : même si une entrée générait un astérisque, les comptes réels possédaient de véritables empreintes cryptographiques avec lesquelles aucune correspondance n’était possible.
C’est la logique de sel d’OpenSSH qui a introduit la faille fatale. Dans les environnements minimaux sans PAM, le processus sshd valide lui-même les mots de passe. Pour ne pas trahir le statut du compte par le temps de réponse, OpenSSH applique le calcul de chiffrement même aux comptes verrouillés.
Le flux d’authentification s’est ainsi retrouvé piégé. OpenSSH pensait vérifier un mot de passe soumis, alors que la bibliothèque avait en réalité renoncé au calcul. Cette divergence contractuelle a transformé un verrou statique en passe-partout.
Le risque latent des images cloud : Un utilisateur ajouté suffit à amorcer la faille
Après la divulgation, la communauté a rapidement évalué l’impact réel. Toutes les installations Alpine ne sont pas exposées ; le risque dépend étroitement de la configuration.
Les conteneurs légers dédiés uniquement à des microservices n’exposent généralement pas de port SSH, ce qui neutralise le vecteur. Les serveurs configurés avec l’authentification par mot de passe désactivée (PasswordAuthentication no) sont également préservés. De même, les systèmes exploitant des modules PAM confient la validation à des composants distincts, évitant cette comparaison de chaînes directe.
Le piège résidait principalement dans les modèles pour le cloud. Les images officielles tiny-cloud d’Alpine (versions 3.18.11 à 3.24.3) intégraient un compte initial nommé alpine. Dans /etc/shadow, son mot de passe était *, complété par des privilèges sudo sans mot de passe.
Sur une instance tout juste initialisée, ce compte ne posait aucun danger immédiat : en l’absence d’autre compte avec empreinte, OpenSSH ne pouvait pas emprunter de sel et n’activait jamais le calcul fictif. Beaucoup d’administrateurs ont ainsi cru que le modèle par défaut était invulnérable.
Le risque explosait dès que l’administrateur créait son premier compte régulier. Dès lors qu’un compte métier avec mot de passe était ajouté dans shadow, le compte dormant alpine devenait une porte dérobée permettant une élévation de privilèges à distance. Un attaquant pouvait alors s’y connecter avec un mot de passe de 257 octets et obtenir les droits root instantanément.
Redémarrage obligatoire après mise à jour : Désactiver les mots de passe en urgence
Aucun identifiant CVE dédié n’a été attribué lors de la publication initiale. Le chercheur Özgün Kültekin a découvert l’anomalie, conduisant à une correction rapide par les équipes d’OpenSSH et d’Alpine. Le correctif a été consigné dans les notes de version d’OpenSSH 10.6p2 et rétroporté sur les branches Alpine 3.16 à 3.24 ainsi que edge.
Les systèmes concernés doivent actualiser leurs dépôts et appliquer la mise à jour sans tarder. La commande apk upgrade -U -a remplace OpenSSH par la version corrigée, qui filtre rigoureusement les caractères anormaux renvoyés par la bibliothèque et empêche toute confusion sémantique.
Figure : Notes de version d’OpenSSH 10.6p2 détaillant la correction relative aux mots de passe surdimensionnés et au sel fictif. Source : openssh.com.
Il est primordial de noter que le remplacement des fichiers sur disque n’élimine pas le risque pour les processus en cours d’exécution. L’ancien démon reste actif en mémoire vive. Les administrateurs doivent impérativement exécuter rc-service sshd restart pour charger le binaire corrigé.
Sur les serveurs en production où un redémarrage immédiat n’est pas envisageable, désactiver l’authentification par mot de passe constitue une mesure d’urgence efficace. Il suffit d’inscrire PasswordAuthentication no dans /etc/ssh/sshd_config.d/00-no-passwords.conf, de recharger le service et de valider la configuration avec sshd -T. Lors de l’audit des journaux, la présence de connexions réussies pour des comptes sans mot de passe dans /var/log/messages indique une compromission probable.
La sécurité logicielle s’effondre fréquemment aux frontières entre sous-systèmes. Quand chaque brique suit individuellement les meilleures pratiques défensives mais diverge subtilement sur la signification d’un symbole d’interface, l’édifice s’effrite de l’intérieur. Garantir une sémantique unique et sans ambiguïté reste un principe d’ingénierie plus fondamental encore que l’accumulation de contrôles de sécurité.
Liens de référence :
- Bulletin de sécurité Alpine Linux
- Notes de version OpenSSH 10.6p2
- Discussion technique sur Lobsters
