Sshole montre que configurer SSH puis l'oublier est une mauvaise habitude

Quand avez-vous réellement pensé à votre démon SSH pour la dernière fois ? Si la réponse honnête est « à l'installation du serveur », vous êtes dans le même bateau que la majeure partie d'internet, et un petit site tout en franchise est là pour vous titiller.

Le site s'appelle sshhole.com, aussi connu sous le nom de sshole, et son message tient en une ligne: OpenSSH sous Linux musl laisserait entrer dans des comptes sans mot de passe depuis 2016. C'est tout ce que nous avons. La page que nous avons consultée n'est pas datée et ne fournit aucune analyse technique; nous ne pouvons donc ni expliquer le mécanisme exact, ni confirmer l'affirmation, ni vous donner un score d'exploitabilité. Considérez-la comme une allégation à prendre au sérieux, et non comme un fait établi.

Le plus inquiétant n'est pas la faille, c'est le « depuis 2016 »

Tout logiciel a des bogues. Ce qui rend cette affirmation si piquante, c'est la durée. OpenSSH jouit de l'une des meilleures réputations de l'open source, et sa propre page de sécurité mentionne d'anciennes catégories d'attaques auxquelles il n'a jamais été vulnérable. Cette réputation est méritée. C'est aussi précisément pour cela qu'on cesse de regarder.

La confiance est une forme de dette technique. Quand un composant est sans histoire depuis des années, personne ne vérifie sa configuration, personne ne se demande ce qui se passe avec une libc inhabituelle, et personne ne l'inscrit dans un calendrier de correctifs. Nous pensons que cette complaisance, plus que n'importe quel bogue isolé, est le vrai sujet. Un compte sans mot de passe est une bizarrerie mineure sur bien des machines, de celles qu'on balaie d'un haussement d'épaules. Associé à un démon qui vous laisse entrer quand même (si l'affirmation se vérifie), cela cesse d'être une bizarrerie.

SSH est un point de défaillance unique, et nous l'avons voulu ainsi

SSH est la porte d'entrée des serveurs, des conteneurs, des routeurs, des machines de build et du Raspberry Pi oublié dans un coin. Quand il cède, ce n'est pas une application qui tombe, mais ce qui protège tout le reste. Nous avons banalisé cette concentration du risque parce que l'outil est bon, mais bon ne veut pas dire infaillible.

Ce ne serait pas non plus la première fois. Le site de suivi IsItPatched recense 50 CVE connues pour OpenSSH, dont deux critiques (la page n'est pas datée, ce chiffre est donc un instantané). BleepingComputer a relaté des mises à jour de sécurité d'OpenSSH corrigeant une faille d'interception (man-in-the-middle) et une faille de déni de service, l'une d'elles ayant été introduite il y a plus de dix ans. Notre lecture: le vieux code cache de vieux problèmes, qui refont surface à leur propre rythme.

Ce que les administrateurs devraient faire

Premièrement, surveillez les avis de sécurité de votre distribution et appliquez les mises à jour d'OpenSSH dès leur publication, surtout si vous utilisez musl quelque part. Nous ne pouvons pas vous dire quelle version corrige ce que dénonce sshole, car la documentation que nous avons consultée ne le précise pas. Lisez l'avis de votre distribution plutôt que de supposer qu'une seule commande règle l'affaire.

Deuxièmement, recherchez les comptes dont le mot de passe est vide ou verrouillé. Ne comptez pas sur le démon pour les refuser. Si l'affirmation de sshole se confirme, c'est justement ce filet de sécurité qui a lâché.

Troisièmement, réduisez l'exposition. Placez SSH derrière un VPN ou une liste d'adresses autorisées, ne laissez pas le port 22 ouvert au monde entier et privilégiez l'authentification par clé. Rien de tout cela ne corrige un bogue du démon, mais « n'importe qui sur internet » devient « quelqu'un déjà dans votre périmètre », un problème bien plus acceptable.

Enfin, le changement de culture: appliquez à OpenSSH la même cadence de correctifs qu'à votre navigateur. Nous ne blâmons pas les mainteneurs. Un projet aussi central mérite à parts égales notre gratitude et notre attention.

Notre verdict

Pas de panique, mais pas de haussement d'épaules non plus. Vérifiez vos comptes sans mot de passe, maintenez OpenSSH à jour et fermez SSH au reste d'internet partout où c'est possible. La leçon de sshole n'est pas qu'OpenSSH est mauvais. C'est que les outils auxquels nous faisons le plus confiance sont ceux que nous avons cessé de surveiller.