OpenSSH 10.6 : signatures post-quantiques, cycle accéléré

OpenSSH 10.6 est sorti le 6 octobre. Cette version active un algorithme de signature hybride post-quantique, affaiblit l'option Compression pour bloquer une attaque entre canaux et corrige plusieurs autres problèmes de sécurité. Les mainteneurs annoncent aussi qu'ils publieront des versions plus souvent pour le moment.

OpenSSH est la suite open source qui assure la plupart des connexions à distance sous Linux, BSD et de nombreux autres systèmes. Elle comprend le serveur sshd, le client ssh et des outils comme sftp et ssh-keygen. Les administrateurs qui utilisent le serveur ou le client doivent s'attendre à des mises à jour plus rapprochées que d'habitude.

Les signalements assistés par IA changent le rythme

Selon l'équipe, ce calendrier accéléré doit permettre de livrer plus vite les correctifs aux utilisateurs. Le projet a reçu un grand nombre de signalements de sécurité. Beaucoup ont été découverts par des modèles d'IA ou avec leur aide. Dans plusieurs cas, un second chercheur a ensuite trouvé le même bug de façon indépendante.

Les mainteneurs en tirent une conclusion claire. Les attaquants qui ne signalent pas les bugs aux projets open source, écrivent-ils, "sont probablement eux aussi capables de découvrir ces bugs".

Cela s'inscrit dans une tendance plus large. D'autres programmes open source peinent face au même afflux, et Google a récemment suspendu son programme de bug bounty OSS à cause des signalements générés par IA.

La compression perd son dictionnaire

ssh et sshd désactivent désormais le codeur à dictionnaire LZ77, ce qui rend l'option Compression moins efficace qu'auparavant. Ce changement fait suite aux travaux de Fabian Bäumer et Marcus Brinkmann. Ils ont décrit une attaque dans laquelle une personne qui contrôle les données d'un canal peut récupérer des secrets transmis sur un autre canal.

Le problème vient du fonctionnement de la compression au sein d'une session. Tous les canaux partagent un seul dictionnaire de compression. Quand des chaînes se répètent d'un canal à l'autre, la longueur du texte chiffré varie, et cette différence laisse fuiter des informations. Les mainteneurs conseillent plutôt de compresser les données au niveau de l'application. Selon eux, c'est en général plus efficace et cela n'est pas concerné par l'attaque.

Les noms d'utilisateur avec $ ou \ sont refusés

Le client ssh rejette désormais les noms d'utilisateur passés en ligne de commande s'ils contiennent un signe dollar ou une barre oblique inversée. Sinon, un nom provenant d'une source non fiable pourrait servir à injecter du code dans un contexte shell via les options ProxyCommand ou Match exec.

Les noms d'utilisateur définis avec la directive User dans les fichiers de configuration ne sont pas concernés. Les mainteneurs précisent qu'une telle mesure d'atténuation ne peut pas être absolue.

Autres correctifs

Plusieurs problèmes moins graves ont aussi été corrigés :

• sshd n'enregistre plus les identifiants GSSAPI qu'après une authentification réussie. Auparavant, les identifiants d'une tentative échouée pouvaient subsister et être exposés lors d'une connexion réussie ultérieure.
• sftp vérifie plus strictement les chemins renvoyés par le serveur. Cela ferme des cas où un serveur malveillant pouvait détourner une copie récursive hors du répertoire cible prévu.
• ssh-keygen gérait mal l'heure d'été. Les certificats pouvaient comporter des dates d'expiration décalées jusqu'à une heure, voire deux heures dans le fuseau Antarctica/Troll.

Sous QNX 6, SCO OpenServer 5 et sur les compilations sans transmission de descripteurs de fichiers, le processus post-authentification conserve les privilèges root. GatewayPorts et StreamLocalForwarding sont désormais désactivés sur ces plateformes. L'équipe indique que leur prise en charge sera abandonnée à l'avenir si aucune solution de remplacement n'est trouvée.

Les clés post-quantiques doivent être remplacées

Cette version active l'algorithme de signature hybride post-quantique ssh-mldsa44-ed25519. Il associe ML-DSA-44 au schéma classique Ed25519. Toute personne ayant généré des clés avec l'ancienne prise en charge expérimentale doit les régénérer ou les supprimer.

Notre analyse

Le plus révélateur dans cette version n'est pas un correctif en particulier, mais l'explication du nouveau calendrier. OpenSSH fait partie des bases de code les plus soigneusement relues de l'open source. Quand ses mainteneurs disent que les outils d'IA font remonter des bugs si vite que des chercheurs indépendants tombent sur les mêmes découvertes, cela laisse penser que le délai entre découverte et exploitation se réduit. Nous avions déjà montré que les divulgations de vulnérabilités doublent à mesure que l'IA accélère l'exploitation, et qu'une faille de Rejetto HFS trouvée par une IA a ensuite été exploitée dans la nature.

Pour les défenseurs, la leçon pratique est de traiter OpenSSH comme un navigateur : appliquer les correctifs vite et souvent. Les équipes qui comptaient sur la compression SSH doivent en tester l'impact, et quiconque a essayé les clés post-quantiques expérimentales doit les renouveler dès maintenant. Reste à voir si d'autres projets d'infrastructure essentiels adopteront des rythmes de publication similaires, et si ce rythme se maintiendra ou se calmera une fois l'arriéré de signalements résorbé.