Un serveur peut chiffrer correctement une connexion tout en laissant entrer la mauvaise personne. C’est le problème central de SSHole, aussi écrit *sshole : un contournement de l’authentification par mot de passe faisant intervenir OpenSSH et la bibliothèque système musl. Dévoilé le 5 novembre 2026 par Özgün Kültekin de Wakefield, il a entraîné la publication de Portable OpenSSH 10.6p2. Annonce d’OpenSSH.
La vulnérabilité porte l’identifiant CVE-2026-123158. Elle concerne certaines configurations de serveurs Linux, pas toutes les installations SSH. Mettre à jour l’application SSH de votre ordinateur ne prouve pas que le serveur distant est corrigé. Fiche CVE.
État des informations au 6 novembre 2026. L’explication technique s’appuie sur la divulgation et le code des projets concernés. Le plan d’action constitue une recommandation pratique de Nuagerie, pas le compte rendu d’une compromission observée chez un client.
Que contourne exactement SSHole ?
SSH sert notamment à administrer des serveurs et à transférer des fichiers. OpenSSH implémente ce protocole ; son processus serveur, sshd, décide d’accepter ou de refuser une connexion. musl est une bibliothèque C utilisée dans certains environnements Linux. PAM est un mécanisme distinct qui peut prendre en charge les vérifications de comptes et de mots de passe.
Dans le chemin vulnérable, l’échec du calcul d’une empreinte de mot de passe renvoie une chaîne spéciale. Le serveur compare cette chaîne au champ de mot de passe enregistré et peut interpréter à tort leur égalité comme une authentification réussie. Il s’agit d’une erreur dans la décision d’authentification, pas d’un mot de passe retrouvé ni d’un algorithme de chiffrement SSH cassé. Le correctif vérifie notamment la longueur minimale du champ enregistré avant d’accepter la comparaison. Correctif OpenSSH.
Pour une entreprise, cette distinction compte : une personne qui atteint le service SSH peut obtenir les capacités d’un compte sans posséder les justificatifs normalement requis. Le pare-feu applicatif qui protège un site Web n’inspecte ni ne corrige, à lui seul, ce mécanisme d’authentification SSH distinct.
Quels systèmes faut-il vérifier ?
L’avis d’Alpine décrit cette combinaison :
- Un serveur OpenSSH non corrigé utilisant musl, sans authentification PAM active.
- L’authentification par mot de passe activée.
- Un compte cible autrement admissible dont le champ de mot de passe contient exactement
*. - Un autre compte local possédant une empreinte de mot de passe
$5$ou$6$. - Un accès réseau au service SSH.
Un conteneur sans sshd n’est pas exposé par ce chemin. Le serveur Alpine avec PAM et UsePAM yes est exclu. Le marqueur exact * compte ; il ne faut pas le confondre avec un verrouillage !. Avis de sécurité d’Alpine.
Ne classez pas un parc uniquement d’après les noms des distributions. Inventoriez le service actif, la bibliothèque, le mécanisme d’authentification, les comptes et les interfaces réseau accessibles. Une image applicative basée sur Alpine n’équivaut pas à une machine virtuelle Alpine offrant un accès d’administration. De même, une adresse privée change qui peut atteindre le service ; elle ne répare pas la vérification du mot de passe.
Utiliser une clé au quotidien ne désactive pas nécessairement la méthode par mot de passe du serveur. Distinguez aussi l’acceptation d’une seule méthode réussie d’une politique qui en exige plusieurs. Contourner le mot de passe ne satisfait pas, à lui seul, une exigence distincte de clé publique réellement imposée. Configuration des méthodes d’authentification OpenSSH.
Comment une erreur devient une connexion acceptée
Un marqueur n’est pas un mot de passe
Une base de mots de passe conserve normalement une empreinte dérivée plutôt que le secret en clair. Un sel participe à ce calcul afin que des mots de passe identiques puissent produire des valeurs enregistrées différentes. Un champ contenant seulement * n’est pas une empreinte utilisable. Ce n’est pas non plus un mot de passe vide : un champ vide et un marqueur d’un caractère sont deux valeurs distinctes.
La divulgation explique pourquoi des comptes destinés à l’accès par clé peuvent porter ce marqueur. Le danger vient de l’acceptation de toute égalité de chaînes comme preuve d’un mot de passe valide, même lorsque les chaînes ne représentent pas un calcul d’empreinte réussi. Explication du chercheur.
Une limite défensive refuse l’entrée
L’implémentation du hachage de mots de passe SHA-512 de musl limite l’entrée à 256 octets pour maîtriser le coût de traitement des mots de passe excessivement longs. Un octet ne correspond pas toujours à un caractère affiché. Cette limite refuse l’entrée trop longue au lieu de la copier au-delà d’une zone mémoire. Implémentation du hachage dans musl.
Historiquement, musl a modifié sa gestion des erreurs pour renvoyer une chaîne ne représentant aucune empreinte valide, plutôt qu’un pointeur nul. Cela aidait à éviter un plantage lorsque le programme appelant ne vérifiait pas ce pointeur. Cette chaîne d’erreur était *. Recevoir une chaîne ne signifie pourtant pas que le calcul a réussi. Modification de musl.
Une protection contre l’analyse temporelle relie les éléments
OpenSSH a introduit une sélection de sel de remplacement afin qu’une authentification refusée effectue un travail de hachage comparable. L’objectif était de réduire les différences de temps pouvant révéler l’existence d’un utilisateur. Le programme peut sélectionner les paramètres d’un autre compte lorsqu’il ne dispose pas d’une empreinte appropriée pour le compte demandé. C’est pourquoi la configuration d’un autre utilisateur intervient, même si l’attaquant ne tente pas de se connecter sous son nom. Modification OpenSSH de 2016.
La séquence devient simple : sélectionner des paramètres, refuser un mot de passe trop long, recevoir *, puis comparer ce résultat au * enregistré pour la cible. Les valeurs correspondent alors qu’aucune empreinte valide n’a été produite. La plage documentée est de 257 à 1024 octets. Aucun secret n’a été deviné et aucune collision cryptographique n’a été découverte. Divulgation.
Pourquoi ce n’est pas un dépassement de tampon
Dans un dépassement de tampon classique, ou buffer overflow, un logiciel écrit au-delà de la mémoire réservée aux données. Cela peut corrompre des données voisines, faire planter le processus ou, dans un cas exploitable, modifier son exécution. Une entrée longue peut déclencher ce problème, mais sa longueur ne suffit pas à établir qu’il y a dépassement de tampon. Définition de MITRE.
| Question | Dépassement de tampon classique | SSHole |
|---|---|---|
| Quel est le problème ? | Une écriture dépasse une limite mémoire. | Un résultat d’erreur devient une preuve d’authentification. |
| Que fait l’entrée longue ? | Elle peut excéder la capacité du tampon de destination. | Elle déclenche le refus de la fonction de hachage. |
| Faut-il écraser de la mémoire ? | Oui, pour le dépassement lui-même. | Non. |
| Que faut-il corriger ? | Les limites mémoire et les opérations dangereuses. | L’interprétation et la validation des résultats d’authentification. |
Cette comparaison explique pourquoi les protections contre l’exploitation mémoire ne réparent pas cette décision de connexion. Le programme peut rester stable, renvoyer une réussite ordinaire et violer malgré tout sa politique de sécurité. Inversement, les dépassements de tampon ne constituent pas une ancienne catégorie définitivement réglée : une nouvelle erreur logique ne rend pas la sécurité mémoire inutile.
Est-ce la même chose que regreSSHion ?
Non. Le problème OpenSSH de 2024 appelé regreSSHion, CVE-2024-6387, concernait une condition de concurrence dans un gestionnaire de signal et une possibilité d’exécution de code arbitraire. L’annonce d’OpenSSH 9.8 décrivait une exploitation démontrée sous Linux/glibc 32 bits, avec des tentatives répétées et des conditions exigeantes. SSHole concerne l’acceptation du mot de passe dans un autre chemin d’authentification. Il faut donc associer l’évaluation du risque et les versions correctives à la bonne vulnérabilité. Notes de sécurité d’OpenSSH 9.8.
Que pourrait faire un attaquant ?
La première question est de savoir quels pouvoirs le compte obtenu possède. Notre analyse des conséquences distingue plusieurs possibilités :
- Un compte de déploiement peut permettre de remplacer des fichiers applicatifs ou de lire des identifiants de déploiement.
- Un compte donnant accès aux sauvegardes ou au stockage partagé peut exposer des données dépassant l’application principale du serveur.
- Un compte de transfert restreint peut n’exposer que les fichiers autorisés, selon son confinement réel.
- Un compte d’administration peut permettre de modifier des services, des utilisateurs, des paramètres de sécurité ou des journaux.
Ce sont des conséquences possibles à examiner, pas une affirmation que chaque serveur exposé donne un contrôle complet. L’accès root dépend du compte et des règles applicables. PermitRootLogin prohibit-password interdit l’authentification root par mot de passe, mais ne limite pas les privilèges administratifs qu’un autre compte peut ensuite exercer. Politique de connexion root.
De même, entrer dans un conteneur ne donne pas automatiquement le contrôle de son hôte. Les secrets montés, les volumes partagés, les paramètres privilégiés et l’accès aux sockets d’administration déterminent la portée possible. L’évaluation métier doit couvrir la confidentialité, les modifications non autorisées, l’interruption et la reprise, sans s’arrêter à l’obtention d’un terminal.
Quelles mesures prendre maintenant ?
Identifier et réduire l’exposition
Demandez à l’administrateur responsable d’identifier les systèmes concernés, y compris les images infonuagiques, les équipements et les conteneurs qui exécutent réellement SSH. Priorisez les services d’administration accessibles et les comptes disposant d’accès sensibles. Restreignez les accès réseau inutiles pendant la préparation du correctif.
Lorsque cela convient, désactivez l’authentification par mot de passe au moyen d’une politique effective PasswordAuthentication no. Vérifiez d’abord un autre accès administratif fonctionnel. Incluez la configuration conditionnelle dans l’examen ; voir une directive dans un fichier ne prouve pas la politique appliquée à chaque utilisateur. Fonctionnement de la configuration OpenSSH.
Appliquer le correctif du fournisseur et l’activer
Portable OpenSSH 10.6p2 contient la mesure corrective du projet. Les paquets d’une distribution peuvent intégrer un correctif rétroporté sans adopter ce numéro de version. Annonce OpenSSH.
Pour Alpine, consultez le tableau des paquets corrigés par branche dans l’avis. La mise à jour doit être suivie d’un redémarrage de sshd; installer de nouveaux fichiers ne remplace pas le processus déjà actif. Instructions et paquets corrigés d’Alpine.
Nous recommandons de conserver comme preuves le paquet serveur et sa révision, le correctif correspondant du fournisseur, la confirmation que le nouveau service fonctionne et une nouvelle connexion autorisée réussie. Préservez un accès de secours pendant l’intervention. Pour les systèmes immuables, reconstruisez aussi l’image source et remplacez les instances concernées afin que le prochain déploiement ne réintroduise pas le paquet vulnérable.
Ne remplacez pas cette vérification par la version du client local ssh ou par le résultat d’un outil qui examine seulement la bannière. Documentez les exceptions et leurs responsables. Évitez les modifications improvisées des marqueurs de mots de passe : le verrouillage d’un compte peut toucher les accès légitimes autant que l’authentification par mot de passe.
Enquêter indépendamment de la correction
Un correctif ferme le chemin vulnérable ; il ne supprime pas les accès qu’un intrus aurait déjà établis. Examinez les authentifications par mot de passe réussies qui contredisent la politique prévue, les adresses sources inhabituelles, les nouvelles clés, les modifications de comptes et les activités administratives inattendues.
Recoupez les événements avec l’historique de configuration et les interventions autorisées. Une réussite inexpliquée mérite une enquête, mais une ligne de journal ne prouve pas à elle seule le mécanisme utilisé. N’activez pas la journalisation des mots de passe en clair pour rechercher des entrées longues. Des journaux absents ou supprimés par rotation limitent aussi les conclusions possibles.
Si un accès non autorisé est confirmé ou fortement soupçonné, préservez les preuves, isolez le système, évaluez les identifiants exposés et planifiez une reprise à partir de sources fiables. Changer les mots de passe sur un hôte encore contrôlé par un attaquant ne constitue pas un plan de rétablissement complet.
Ce que cela signifie pour votre entreprise
Demandez à la partie responsable du système d’exploitation une réponse claire : quels systèmes ont été vérifiés, lesquels étaient touchés, quels correctifs sont actifs et si une activité suspecte exige un suivi. Le propriétaire de l’application et l’administrateur de son hébergement peuvent être deux organisations différentes ; le périmètre de maintenance doit préciser qui accomplit chaque tâche.
SSHole montre pourquoi les vérifications de sécurité doivent couvrir les interactions entre composants. Une limite de hachage, un marqueur d’erreur et une protection temporelle peuvent chacun répondre à un objectif raisonnable, tout en produisant ensemble une décision dangereuse. Pour une organisation, le résultat utile reste un inventaire vérifié, un correctif actif et une évaluation des accès antérieurs fondée sur des preuves.