OpenSSH accélère ses versions face aux failles trouvées par IA

OpenSSH est une version libre de SSH, le protocole qui ouvre une session chiffrée sur une machine distante pour l’administrer ou y copier des fichiers. Il est développé au sein du projet OpenBSD, et Microsoft le propose aussi comme fonctionnalité de Windows depuis Windows 10 (build 1809) et Windows Server 2019.

Ce qu’une IA trouve, un attaquant peut le trouver

Le raisonnement tient en trois phrases, en tête des notes de version : « Nous avons vu un certain nombre de cas où une faille de sécurité identifiée par des outils d’IA a ensuite été découverte indépendamment par un autre chercheur. Cela laisse penser que des adversaires qui ne signalent pas les failles aux projets open source sont probablement capables de les découvrir eux aussi. En conséquence, l’équipe d’OpenSSH publiera, pour l’instant, des versions plus fréquentes, pour mettre les correctifs plus vite entre les mains des utilisateurs, au lieu de les regrouper jusqu’à la prochaine version prévue. »

Le même paragraphe apparaissait déjà, mot pour mot, dans les notes d’OpenSSH 10.5, le 11 août ; il était absent de celles de la 10.4, publiée le 6 juillet. Le ton tranche avec celui d’autres acteurs du logiciel libre. Google a suspendu le 1^er octobre ses primes pour les failles du code de ses logiciels libres, en invoquant un afflux de rapports automatisés en majorité invalides. OpenSSH fait le même constat sur la qualité (« beaucoup de rapports d’IA s’avèrent sans impact sur la sécurité une fois replacés dans un modèle de menace réaliste »), mais dit les accueillir « très volontiers », surtout quand ils arrivent avec un tri humain, une analyse, des cas de test et un correctif proposé.

Dans la 10.6, deux mentions seulement associent nommément une IA à une correction, toutes deux au nom de « Chris Rohlf, en collaboration avec Claude et Anthropic Research ». Ce chercheur, présenté dans les notes de la 10.5 comme Christopher Paul Rohlf, « d’Anthropic », est crédité pour une faille dans la lecture de la configuration du serveur, et pour un renforcement rangé parmi les corrections ordinaires : le type d’une clé est désormais contrôlé le plus tôt possible, dès sa lecture. Une autre faille est créditée à « SecBuddyF KeenLab Tencent (CodeBuddy Security) » ; CodeBuddy est l’environnement de programmation assisté par IA de Tencent Cloud, mais la mention ne précise pas comment la faille a été trouvée. Pour les autres correctifs, les notes ne disent rien des outils employés.

Un rythme à relativiser

Sur le papier, l’accélération est réelle, mais récente. D’après l’historique des versions, 202 jours séparent la 9.9 (19 septembre 2024) de la 10.0 (9 avril 2025), 180 jours la 10.0 de la 10.1 (6 octobre 2025), et 174 jours la 10.2, une version de dépannage sortie quatre jours après la 10.1, de la 10.3 (2 avril 2026). Puis l’écart tombe à 95 jours jusqu’à la 10.4 et à 36 jours jusqu’à la 10.5, avant de remonter à 56 jours jusqu’à la 10.6.

Compté par année, le rythme n’a pourtant rien d’inédit : 2026 compte quatre versions à la mi-octobre, quand 2023 en avait connu six (9.2, 9.3, 9.3p2, 9.4, 9.5 et 9.6). Ce qui change, c’est la règle annoncée : les correctifs ne doivent plus attendre.

La faille la plus étudiée : la compression

Le correctif le plus documenté répond à un article de deux chercheurs de l’université de la Ruhr à Bochum, Fabian Bäumer et Marcus Brinkmann, publié en prépublication sur arXiv et accepté à la conférence ACM CCS 2026. Les deux auteurs avaient déjà présenté, avec Jörg Schwenk, l’attaque Terrapin contre SSH, corrigée par OpenSSH 9.6 en décembre 2023.

Le principe rappelle les attaques CRIME et BREACH contre HTTPS, que l’article cite. Une connexion SSH peut transporter plusieurs « canaux » à la fois (on parle de multiplexage) : une session de terminal, un port réseau redirigé vers la machine locale, une deuxième session ouverte dans le même tuyau. Quand la compression est activée, tous ces canaux partagent le même « dictionnaire », la mémoire des séquences déjà vues qui permet de ne pas les répéter. Un attaquant qui peut injecter du texte de son choix dans un canal, puis observer la taille des paquets chiffrés, voit celle-ci diminuer quand son essai coïncide avec un secret qui circule dans un autre canal. Il devine ainsi le secret morceau par morceau, sans rien déchiffrer. Dans le scénario le moins bruité de l’article, un secret de huit caractères pris dans un alphabet de 26 lettres est retrouvé « en 276 essais au plus ».

Les conditions sont étroites. Selon l’article, l’attaquant doit voir passer le trafic chiffré et pouvoir injecter du texte, soit en se connectant directement à un port exposé, soit par un script exécuté dans le navigateur de la victime qui vise un port redirigé. Côté victime, la compression doit être active. Le client OpenSSH ne la demande pas par défaut (Compression no), même si le serveur l’accepte par défaut (Compression yes) ; sur 33 clients SSH étudiés par les chercheurs, quatre seulement la préfèrent par défaut. OpenSSH 10.6 désactive la partie du compresseur qui exploite ce dictionnaire. Contrepartie annoncée : la compression sera « moins efficace ».

Ce qui peut demander une intervention

La plupart des corrections n’exigent rien d’autre que la mise à jour. Cinq changements peuvent en revanche se remarquer.

• Les noms d’utilisateur contenant $ ou \ sont refusés en ligne de commande. Le client SSH peut lancer des commandes locales construites avec le nom d’utilisateur (options ProxyCommand, qui définit comment joindre le serveur, et Match exec, qui applique une partie de la configuration selon le résultat d’une commande) ; un nom venu d’une source non fiable pouvait y glisser des instructions pour l’interpréteur de commandes. Effet de bord possible : Microsoft documente la forme ssh domain\username@servername pour se connecter à un serveur Windows avec un compte de domaine. Les notes précisent que le contrôle vise les noms « entrés en ligne de commande » : un nom inscrit dans un fichier de configuration, par la directive User, n’y est pas soumis. D’après ces notes, c’est donc par cette voie qu’un compte de la forme domain\username reste accepté. La version livrée avec Windows est maintenue par Microsoft et mise à jour par Windows Update : rien n’indique encore quand elle intégrera ce changement.
• Les clés post-quantiques d’essai sont à refaire. La 10.6 active ssh-mldsa44-ed25519, un algorithme de signature « hybride » qui associe Ed25519, la méthode classique, à ML-DSA, normalisé par le NIST américain en 2024 et réputé sûr « même face à un adversaire disposant d’un ordinateur quantique de grande taille ». Le nom ne porte plus le suffixe @openssh.com de la version expérimentale : les clés créées avec celle-ci « doivent être régénérées et/ou supprimées ».
• La copie d’un serveur distant à un autre par scp -R est en sursis. L’option, qui fait exécuter la copie par une machine distante, affiche désormais un avertissement et sera ignorée dans une version future ; les notes la jugent fragile et risquée quand les règles de l’interpréteur distant diffèrent de celles attendues.
• Le serveur signale les échanges de clés non post-quantiques. L’option WarnWeakCrypto, jusqu’ici réservée au client, arrive dans le serveur, activée par défaut : elle inscrit au journal les connexions dont l’échange de clés ne résiste pas à un futur ordinateur quantique. Les journaux peuvent donc grossir sur un parc de clients anciens.
• Deux options de redirection sont coupées sur quelques systèmes rares. Sur QNX 6, SCO OpenServer 5 et les compilations faites avec l’option --disable-fd-passing, le processus qui sert la session gardait les privilèges de l’administrateur (root), et pouvait contourner des restrictions imposées à l’utilisateur. GatewayPorts et StreamLocalForwarding y sont désactivées, et la prise en charge de ces plateformes pourrait disparaître.

Les correctifs de sécurité d’OpenSSH 10.6, un par un

• sftp (client de transfert de fichiers) : un serveur malveillant pouvait renvoyer des chemins qui faisaient écrire une copie récursive hors du dossier visé. Signalé et corrigé par Junghoon Cho.
• sshd (serveur), authentification GSSAPI (le mécanisme qui s’appuie sur Kerberos, courant dans les annuaires d’entreprise, désactivé par défaut) : les identifiants d’une tentative échouée pouvaient rester disponibles si une autre méthode réussissait ensuite ; l’état d’une tentative pouvait aussi se mêler à celui de la suivante. Signalé par Moritz Theile.
• ssh et sshd, compression : désactivation du codage par dictionnaire, contre l’attaque de Fabian Bäumer et Marcus Brinkmann.
• ssh (client) : refus de $ et \ dans les noms d’utilisateur saisis en ligne de commande. Signalé par SecBuddyF (KeenLab, Tencent, CodeBuddy Security).
• ssh-keygen : le passage à l’heure d’été était mal pris en compte dans la conversion des dates, d’où des certificats dont l’expiration pouvait être décalée d’une heure (deux heures dans le fuseau de la base antarctique de Troll).
• ssh et sshd : une charge compressée ne peut plus dépasser, une fois décompressée, la taille maximale d’un paquet. Signalé par Oleh Konko.
• sshd : le mot-clé restrict des fichiers authorized_keys s’applique pleinement aux tunnels (PermitTunnel, désactivé par défaut). La 10.5 avait déjà corrigé un défaut voisin.
• sshd : certaines options documentées comme acceptant none pour se désactiver, dont AuthorizedPrincipalsFile, prenaient ce mot pour un nom de fichier quand elles étaient redéfinies dans un bloc Match. Avec Chris Rohlf, « en collaboration avec Claude et Anthropic Research ».
• sshd sur macOS : le bac à sable (le cloisonnement du processus) n’est plus pris en charge avec le kit de développement d’Apple version 27 et suivantes, dont l’interface a été retirée.
• sshd sur QNX 6, SCO OpenServer 5 et compilations sans passage de descripteurs : privilèges d’administrateur conservés après l’authentification, d’où la désactivation de GatewayPorts et StreamLocalForwarding. Signalé séparément par sn0x-sharma et par Dark River.

Gravité : des notes faibles, attribuées hors du projet

Les notes du projet, comme l’annonce sur la liste oss-security, ne donnent ni identifiant CVE (le numéro de référence international des failles) ni niveau de gravité. L’organisme MITRE, qui attribue ces numéros, en a pourtant publié dès le 6 octobre pour au moins cinq correctifs : les deux défauts de l’authentification GSSAPI, la compression, les noms d’utilisateur et le bac à sable de macOS. Les notes de gravité qu’il y associe, sur l’échelle CVSS qui va de 0 à 10, sont faibles : de 2,2 pour GSSAPI à 3,7 pour la compression. La plupart des descriptions donnent en revanche les conditions de la faille : un serveur malveillant pour sftp, l’authentification GSSAPI activée, un nom d’utilisateur fourni par un tiers, la compression demandée par le client, des tunnels autorisés alors qu’ils sont désactivés par défaut, une option redéfinie dans un bloc Match, ou une plateforme marginale. Seule la limite imposée aux données compressées est décrite sans conséquence ni condition.

Le numéro de version installé ne dit d’ailleurs pas tout. Les grandes distributions Linux reportent souvent les correctifs sur la version qu’elles livrent plutôt que d’en changer : Debian, par exemple, l’explique dans sa FAQ (« au lieu de passer à une nouvelle version, nous rétroportons les correctifs de sécurité sur la version livrée dans la version stable »). Son suivi de sécurité classe d’ailleurs la faille de compression et celle des noms d’utilisateur parmi les problèmes mineurs : au 16 octobre, ni Debian 12 (OpenSSH 9.2) ni Debian 13 (OpenSSH 10.0) n’en avaient reçu le correctif. Un serveur qui affiche une version 9 ou 10.0 peut donc avoir reçu une partie de ces correctifs, ou aucun : c’est le bulletin de sécurité de la distribution qui le dit, au fil des versions qu’OpenSSH promet désormais plus rapprochées.

Les citations en anglais sont traduites par la rédaction. Les agents qui préparent les articles de L’Octet s’appuient sur un modèle d’Anthropic, dont le modèle Claude est crédité dans deux des corrections décrites ici.