10 min de lecture - OpenSSH sur Alpine : prouvez l’exposition, puis le redémarrage

OpenSSH a publié Portable OpenSSH 10.6p2 le 5 novembre 2026 avec un contournement critique pour une faille d’authentification par mot de passe. L’avis amont limite le problème à certains systèmes Linux qui utilisent la libc musl avec PAM désactivé. Le même jour, le CERT-FR a averti que le contournement devient trivial lorsque toutes les conditions sont réunies.

Ces premiers avis exposent à deux erreurs de tri. Une équipe cherchera uniquement la chaîne amont OpenSSH 10.6p1, alors que la plage concernée couvre toutes les versions d’OpenSSH antérieures à 10.6p2 sur ces compilations et que les correctifs d’Alpine pour les anciennes branches gardent leurs propres numéros de version. Une autre déclarera compromis chaque conteneur Alpine, alors qu’un conteneur qui n’exécute pas sshd n’est pas touché.

Posez une question plus précise : quels services SSH accessibles réunissaient le runtime, le chemin d’authentification et l’état des comptes concernés, puis lesquels exécutent maintenant un démon corrigé ? Répondez avec les preuves du système actif, pas avec l’étiquette d’une image ou le reçu d’installation d’un paquet.

L’exposition dépend d’une chaîne de conditions

La note de version OpenSSH 10.6p2 décrit un contournement via sshd sur certains systèmes Linux exécutés sans PAM. L’avis de sécurité Alpine documente la conjonction complète pour cette distribution :

• sshd fonctionne sur musl, avec le paquet serveur Alpine sans PAM ou une compilation PAM réglée sur UsePAM no ;
• la configuration effective autorise l’authentification par mot de passe ;
• un compte possède * dans son champ de mot de passe (Alpine cite notamment les comptes à clé seule, les comptes d’annuaire et root, joignable seulement si PermitRootLogin yes est défini) ;
• au moins un compte local possède un hachage $5$ ou $6$ ;
• un attaquant atteint le service SSH et connaît ou devine le nom du compte étoilé.

Dans cette configuration, un mot de passe de 257 à 1 024 octets (chiffres d’Alpine ; d’autres sources donnent des bornes légèrement différentes) peut faire correspondre l’échec de crypt() au champ *. Alpine indique qu’une seule connexion suffit. L’avis d’Alpine a été rédigé avant l’attribution d’un identifiant CVE. Le MITRE a publié CVE-2026-123158 plus tard le 5 novembre, et le CERT-FR l’a ajouté le 6 novembre. La fiche CVE indiquant la plage amont alors que les paquets corrigés d’Alpine gardent d’anciens numéros de version, vérifiez la version du paquet de la distribution au lieu de vous fier aux seules correspondances CVE.

Ne réduisez pas la chaîne à « Alpine est vulnérable ». Alpine exclut explicitement les systèmes avec PasswordAuthentication no, ceux qui utilisent PAM avec UsePAM yes, les comptes verrouillés dont le champ commence par !, et les conteneurs sans sshd. Les systèmes glibc et OpenBSD sortent aussi de la condition précise décrite dans l’analyse technique du chercheur. Les autres produits fondés sur musl exigent une preuve de leur éditeur ou de leur compilation ; le tableau des paquets Alpine ne démontre pas leur état.

Inventoriez le service réellement exécuté

Commencez par les points d’accès SSH à l’écoute : instances cloud publiques, passerelles, appliances, machines de compilation et anciens hôtes de reprise. Une nomenclature logicielle aide à trouver des candidats, mais la décision exige l’état déployé de chaque point d’accès.

Consignez les valeurs effectives appliquées par sshd. sshd_config peut inclure des fichiers additionnels, et un bloc Match peut modifier une option selon l’utilisateur, l’adresse ou le groupe. Utilisez sshd -T avec le contexte de connexion pertinent si nécessaire, puis conservez la sortie dans le ticket. Une seule ligne trouvée par recherche textuelle constitue une preuve plus faible.

Distinguez l’emploi d’une image de base de celui d’un serveur SSH. Alpine précise que Docker et les autres conteneurs sans sshd ne sont pas touchés. Si l’équipe trouve le paquet Alpine dans une image applicative, demandez si le démon existe, démarre et expose un port avant d’ouvrir un incident. Vérifiez aussi le cas inverse : une petite VM créée hors de la chaîne d’infrastructure habituelle peut exécuter sshd sans figurer dans l’inventaire des images.

Fermez l’accès et vérifiez le processus actif

Pour Alpine, la première consigne de l’éditeur consiste à mettre openssh à jour puis à redémarrer sshd. Le redémarrage forme un contrôle séparé : Alpine avertit que la mise à niveau du paquet ne remplace pas le démon actif. La mise à jour du CERT-FR du 6 novembre précise que tout correctif ou changement de configuration doit s’accompagner d’un redémarrage de sshd. Les branches stables prises en charge reçoivent des correctifs rétroportés. Un hôte peut donc être corrigé sans afficher la version amont 10.6p2.

Consignez la branche de distribution, l’ancien paquet, le paquet corrigé indiqué par l’éditeur, le résultat de la mise à niveau, l’heure de redémarrage du service et celle du nouveau processus. Ouvrez ensuite une nouvelle session SSH par le chemin prévu avec clé. Gardez la session initiale disponible jusqu’à la réussite du nouveau test, car une modification d’urgence peut exclure l’opérateur chargé de la terminer.

Si vous ne pouvez pas appliquer le paquet immédiatement, Alpine et le CERT-FR recommandent de désactiver l’authentification par mot de passe ; à défaut, le CERT-FR préconise de désactiver le service. Testez d’abord l’accès par clé, appliquez le réglage, validez la configuration, redémarrez le démon et contrôlez la valeur effective. Un fichier modifié sans redémarrage laisse la main à l’ancien processus.

Ne traitez pas la modification des comptes comme l’unique mesure d’urgence. La condition vulnérable peut couvrir root, des utilisateurs à clé seule et des comptes d’annuaire, puis l’état local changera peut-être plus tard. La désactivation des mots de passe ou l’arrêt du service joignable agit sur la voie d’entrée, indépendamment de la liste actuelle des comptes.

Déterminez si l’exposition est devenue un incident

Alpine et le chercheur cité dans l’alerte du CERT-FR recommandent de rechercher les connexions par mot de passe réussies pour les comptes dont le champ /etc/shadow vaut * ; sur Alpine, cherchez les lignes Accepted password for de sshd dans /var/log/messages. Alpine suggère aussi d’examiner l’usage de doas, les utilisateurs récemment créés, les fichiers et les clés autorisées. Préservez les journaux SSH locaux, ainsi que les traces distantes d’authentification, de pare-feu ou de flux cloud, avant qu’une rotation ou une reconstruction n’efface le contexte.

Construisez la période d’exposition entre le premier instant où toutes les conditions étaient réunies et le démarrage du démon corrigé. Un ancien paquet vulnérable ne suffit pas à établir toute la période. Le service pouvait être inaccessible, les mots de passe pouvaient être désactivés ou l’état de compte requis pouvait n’apparaître qu’après le provisionnement.

Un événement « Accepted password » correspondant à un compte étoilé constitue une preuve forte d’un accès non autorisé et doit entrer dans votre procédure d’incident. L’absence de journal ne prouve pas l’absence d’accès : la rétention peut être courte, le point d’accès peut écrire ailleurs ou un attaquant peut avoir modifié la machine. Qualifiez cet état d’« exposé, résultat inconnu », puis laissez le responsable d’incident décider de l’isolement, du renouvellement des accès et d’une reconstruction.

Alpine décrit un cas distinct, propre aux images cloud ; nous le vérifierions en premier. Les images tiny-cloud officielles de 3.18.11 à 3.24.3 contiennent un utilisateur alpine avec un champ * et un accès doas sans mot de passe ; l’image devient exploitable dès qu’un autre hachage admissible existe. Les images construites à partir des versions 3.21.10, 3.22.8, 3.23.8, 3.24.4 ou ultérieures comprennent le paquet corrigé. Vérifiez chaque instance active, car reconstruire une image ne met pas à jour une VM déjà créée.

Gardez un dossier de clôture assez court pour être terminé

Utilisez quatre états plutôt qu’un long récit dans le suivi d’incident :

Ce dossier révèle aussi un problème de chaîne logicielle. « Nous utilisons Alpine » ne donne pas assez de détails pour déterminer le comportement de l’authentification. La libc d’exécution, les choix de compilation, l’état de PAM, la configuration du démon et le provisionnement des comptes ont tous participé. Ajoutez ces propriétés aux tests de vos images de référence qui exécutent volontairement SSH, puis vérifiez que les mots de passe restent désactivés lorsque l’architecture prévoit un accès par clé uniquement.

Notre guide sur la reconstruction de la confiance dans la supervision après un contournement d’authentification explique comment traiter les preuves issues d’un système potentiellement modifié. L’approche cybersécurité et ingénierie d’Exceev peut relier le correctif urgent à la politique d’image, aux contrôles de déploiement et aux responsabilités d’exploitation.

Sources et limites

Nous avons ouvert et vérifié chaque source ci-dessous le 6 novembre 2026.

• La note de version Portable OpenSSH 10.6p2 fournit la déclaration amont sur le contournement, la condition d’exécution et la date de publication.
• L’avis de sécurité Alpine Linux précise les conditions de la distribution, les branches corrigées, le redémarrage, le périmètre des images cloud et les conseils d’investigation.
• L’alerte CERTFR-2026-ALE-015 résume pour le public français le risque, les versions amont concernées et la mesure temporaire, à partir des bulletins OpenSSH et Alpine. Elle relaie la vérification des journaux proposée par le chercheur, et sa mise à jour du 6 novembre ajoute l’identifiant CVE et le redémarrage obligatoire de sshd.
• La fiche CVE-2026-123158, publiée par le MITRE le 5 novembre, donne l’identifiant et la plage concernée : OpenSSH avant 10.6p2 sous Linux, avec la libc musl et sans PAM.
• La publication du chercheur explique l’échec de crypt(), la longueur du mot de passe, la méthode de découverte et les comptes concernés. Nous l’utilisons pour le contexte technique ; les consignes des éditeurs et du CERT dirigent la correction.

Nous n’avons ni inspecté l’infrastructure d’un lecteur, ni reproduit le contournement, ni conclu à la compromission d’une organisation. Les versions de paquets, avis et identifiants attribués peuvent changer après cette revue. Les commandes et emplacements de journaux varient selon la distribution et la configuration. Cet article aide à structurer une décision opérationnelle ; il ne remplace pas le support de l’éditeur, la réponse à incident ou une investigation forensique.