OpenSSH 10.5 corrige une faille de l’agent SSH

Tu connais SSH sans le savoir : c’est le tunnel chiffré qui te permet d’administrer ton serveur à distance, d’envoyer des fichiers ou de te connecter à ta machine sans exposer tes mots de passe. OpenSSH, c’est le logiciel qui fait tourner ce protocole, et il équipe presque tous les serveurs de la planète. Le 11 août, il est passé en version 10.5, seulement cinq semaines après la précédente. Ce rythme inhabituel cache deux histoires : une faille qui punissait les prudents, et l’IA qui bouscule la façon dont arrivent les correctifs.

La première histoire est contre-intuitive : verrouiller ton agent SSH, la petite protection que tu actives quand tu t’éloignes de ton clavier, pouvait te rendre moins sûr. La seconde est plus large : l’équipe OpenSSH reconnaît que les rapports de failles venus de l’IA affluent, et qu’elle doit publier plus vite pour garder une longueur d’avance. Détail par détail.

Le logo officiel d’OpenSSH, le logiciel derrière le protocole SSH.

Source : openssh.org

Verrouiller ton agent te rendait moins sûr

L’agent SSH, c’est ce petit programme qui garde tes clés en mémoire pour que tu ne retapes pas ta phrase de passe à chaque connexion. Tu peux le verrouiller quand tu t’éloignes : tant qu’il est gelé, personne ne peut l’utiliser. Sauf que les versions précédentes avaient un défaut dans l’extension qui identifie les agents transférés.

Quand l’agent était verrouillé, les demandes de liaison étaient refusées, et ce refus ouvrait une porte : des opérations censées rester locales pouvaient être déclenchées à distance via un agent transféré. Concrètement, un attaquant ayant accès au socket de l’agent pouvait ajouter des jetons de sécurité matériels ou utiliser des clés auxquelles tu avais pourtant imposé des restrictions de destination.

Autrement dit, la sécurité que tu ajoutais en verrouillant l’agent devenait un angle d’attaque. C’est le genre de bug qu’on découvre rarement en lisant le code, et beaucoup plus souvent en le faisant analyser par une machine.

La rafale ne s’arrête pas là

La même version corrige une faille dans le client SSH : une libération de mémoire déjà utilisée pouvait survenir quand une redirection distante était ajoutée pendant qu’une autre demande était en attente. C’est le genre de bug de mémoire qui demande une course précise pour être exploité, mais qu’on ne laisse pas traîner.

Côté serveur, le mot-clé restrict du fichier authorized_keys ne s’appliquait pas au transfert de tunnel : les administrateurs qui l’utilisaient pour limiter certaines clés pouvaient se faire surprendre. Le tunnel reste désactivé par défaut, mais la restriction s’applique maintenant correctement.

À noter au passage : deux correctifs viennent d’un chercheur d’Anthropic, qui a réduit la surface d’attaque avant authentification et corrigé une double libération dans ssh-keygen. L’IA est dans tous les coins, même dans les correctifs.

Pourquoi l’IA bouscule le calendrier des correctifs

Le plus intéressant dans cette version, c’est ce que l’équipe OpenSSH dit autour. Elle reçoit depuis un moment un grand nombre de rapports de failles issus de modèles d’IA, ou rédigés avec leur aide. Beaucoup se révèlent sans impact réel une fois replacés dans un contexte réaliste, mais certains sont sérieux.

Surtout, l’équipe a observé des failles d’abord identifiées par l’IA puis redécouvertes indépendamment par d’autres chercheurs. Traduction : si les gentils les trouvent, les méchants peuvent les trouver aussi. Plutôt que d’attendre la prochaine version planifiée, OpenSSH publiera désormais plus souvent, pour que les correctifs arrivent plus vite entre les mains des utilisateurs.

C’est un changement de philosophie discret mais important pour tout l’écosystème open source : la cadence des correctifs s’accélère parce que les outils de recherche de failles deviennent eux-mêmes plus intelligents.

Capture de la page des notes de version d'OpenSSH 10.5, avec le passage expliquant que l'équipe reçoit de nombreux rapports de failles issus de l'IA et publiera plus fréquemment — Les notes de version d’OpenSSH 10.5, où l’équipe explique que les rapports de failles issus de l’IA la poussent à publier plus vite.

Source : notes de version officielles, openssh.org

Ce que tu dois faire maintenant

La mise à jour passe par ton gestionnaire de paquets habituel. Sur Debian, Ubuntu ou Fedora, une simple mise à jour du système suffit ; vérifie ensuite ta version avec ssh -V. Si tu héberges tes propres services, redémarre le service sshd après la mise à jour pour que le correctif prenne effet.

Pas de panique : la faille de l’agent exige un accès au socket de l’agent, ce qui n’est pas donné à tout le monde. Mais OpenSSH est tellement central qu’on ne laisse pas traîner ce genre de correctif. Cette semaine, entre Flatpak 1.18.1 et Rsync 3.5, les correctifs de sécurité s’enchaînent : quand la sécurité arrive, on installe.

Au passage, la 10.5 apporte des outils pratiques : ssh -Z te liste les clés qui seront essayées pour une connexion, dans l’ordre, ce qui dépanne quand une authentification rame. Et les clés matérielles FIDO sont mieux gérées, avec des options pour exiger le contact ou la vérification par code PIN.

On a passé vingt ans à dire qu’OpenSSH était le truc à mettre à jour en priorité. La nouveauté, c’est que les robots qui rédigent tes e-mails passent maintenant tes serveurs au peigne fin. La prochaine fois qu’un correctif SSH arrivera plus tôt que prévu, tu sauras pourquoi : merci l’IA, et installe.