La version 10.6 d’OpenSSH comprend deux changements de sécurité susceptibles de casser certains scénarios d’utilisation antérieurs : la désactivation du composant LZ77 responsable de la création d’un dictionnaire de répétitions dans la compression SSH, et le refus des noms d’utilisateur contenant les symboles $ et \ lorsqu’ils sont transmis en ligne de commande. Les développeurs du projet ont pris cette décision en sachant que certains environnements et outils devraient être adaptés.
Pourquoi la compression SSH a-t-elle été affaiblie ?
Une seule session SSH peut transporter un canal de terminal interactif, une redirection de ports ou un proxy SOCKS dynamique. Lorsque la compression était activée, les canaux partageaient un même état de compression. Les chercheurs Fabian Bäumer et Marcus Brinkmann de la Ruhr University Bochum ont montré qu’un attaquant pouvait injecter un texte de son choix dans un canal et surveiller le trafic chiffré afin d’inférer des données secrètes transitant par un autre canal de la même session.
L’attaque repose sur la mémoire LZ77, qui réutilise des séquences apparues précédemment au lieu de les encoder entièrement. Lorsque la supposition de l’attaquant correspond à une partie du secret, le résultat compressé peut devenir légèrement plus court, fournissant ainsi un signal permettant de récupérer les données. Cette technique appartient à la famille des attaques CRIME et BREACH, mais elle nécessite une configuration précise : l’activation de la compression SSH, la possibilité de contrôler une partie du trafic et la présence du secret et du canal attaqué au sein d’une session SSH multicanal.
Dans les tests les moins bruités, les chercheurs ont récupéré un secret de huit caractères issu d’un alphabet de 26 caractères avec une médiane de 276 suppositions sur 100 essais. Dans un scénario fondé sur un navigateur et plus bruité, le nombre est passé à environ 27 600 suppositions. Selon le contenu source, les modèles de preuve de concept ont été construits avec Claude Code.
Qu’est-ce qui change concrètement pour la compression ?
OpenSSH conserve le codage de Huffman, mais désactive la partie LZ77 dans ssh et sshd. La compression ne disparaît donc pas complètement, mais elle devient moins efficace. Le projet indique que les sessions interactives habituelles ne remarqueront généralement pas de différence importante, tandis que les tâches automatisées transférant de grandes quantités de données compressibles sur des connexions à capacité limitée peuvent être affectées.
OpenSSH recommande de déplacer la compression vers la couche applicative, où elle est généralement plus efficace et n’est pas exposée à ce type d’attaque. En pratique, les propriétaires de systèmes d’automatisation qui dépendent de la compression SSH devraient mesurer le volume transféré et le temps d’exécution après la mise à niveau, puis déterminer si la compression des données avant leur envoi est préférable au recours à la compression SSH.
Noms d’utilisateur et chaîne d’automatisation
La version 10.6 refuse les symboles $ et \ dans les noms d’utilisateur transmis en ligne de commande. Cela vise les outils internes, les tâches CI et les agents qui construisent une commande telle que ssh "$INPUT_USER@host", après quoi le nom d’utilisateur peut parvenir à des directives comme ProxyCommand ou Match exec, où ces symboles peuvent être interprétés comme faisant partie d’une construction shell au lieu d’être considérés comme des données ordinaires.
La même restriction ne s’applique pas lorsque le nom d’utilisateur est défini au moyen de la directive User dans un fichier de configuration SSH. Les comptes légitimes contenant ces symboles peuvent donc rester utilisables de cette manière, mais les scripts et outils qui les transmettent directement en ligne de commande peuvent devoir être modifiés. Cette évolution intervient après une correction connexe dans OpenSSH 10.3 : la vérification des caractères shell était effectuée trop tard, ce qui permettait leur arrivée dans le chemin d’expansion de ssh_config.
Autres changements susceptibles d’affecter les flux de travail
- L’algorithme de signature hybride post-quantique ssh-mldsa44-ed25519 a perdu le suffixe expérimental @openssh.com, ce qui signifie que les clés créées avec l’ancienne implémentation doivent être régénérées ou supprimées.
- Le projet a commencé à préparer la suppression de scp -R pour les copies d’un hôte distant vers un autre hôte distant. L’option fonctionne toujours dans la version 10.6, mais elle émet un avertissement et doit être ignorée à l’avenir.
Ces changements montrent que la compatibilité avec le comportement antérieur n’est plus une priorité absolue lorsqu’une utilisation automatisée révèle une voie de fuite de données ou d’injection de commandes. Toutefois, les contraintes pratiques ne sont pas équivalentes : le risque de fuite par la compression nécessite une session et des conditions précises, tandis que le refus de noms d’utilisateur peut apparaître immédiatement dans des scripts dépendant d’entrées externes. Les équipes d’exploitation doivent donc tester la mise à niveau, revoir la construction des commandes SSH et vérifier les clés et les options de copie avant d’adopter largement la version.