Faille telnetd – Accès root avant même le login
Telnet en big 2026… bah oui ça existe encore les amis ! Et surtout c’est toujours aussi troué ! J’en veux pour preuve le daemon telnetd de GNU InetUtils qui vient de se prendre une 2ème faille critique en l’espace de deux mois, et celle-là, elle pique de fou !
Il s’agit de la
CVE-2026-32746
, elle permet d’obtenir un shell root sur n’importe quel serveur Linux ou BSD exposant le port 23, et l’attaque se fait avant même que le prompt de login n’apparaisse. Pas besoin de mot de passe, pas besoin de compte. Juste une bonne vieille connexion TCP et un paquet SLC malformé et c’est parti mon kiki !
En fait, le bug se planque dans le handler SLC (Set Local Characters) du code source C de telnetd. Ainsi, quand un client ouvre une socket TCP sur le port 23, y’a une phase de négociation d’options avant l’authentification. L’attaquant envoie alors un paquet SLC contenant un nombre anormal d’octets, et ça déclenche un buffer overflow de type out-of-bounds write dans la mémoire du processus. Et boom, exécution de code arbitraire avec les privilèges root ! Et ça, ça donne un score CVSS de 9.8 sur 10 soit quasi la note maximale !
Toutes les versions de GNU InetUtils telnetd jusqu’à la 2.7 sont touchées. Toutes vulnérables, et pour le moment, aucun patch n’est disponible à ce jour. C’est la boîte de cybersécurité israélienne Dream, via son chercheur Adiel Sol, qui a découvert le pot aux roses et publié l’advisory le 11 mars dernier. Le patch officiel du mainteneur GNU est attendu pour le 1er avril (et non, c’est pas un poisson).
Ça craint surtout qu’il y a à peine 2 mois, une autre faille critique dans le même daemon, la CVE-2026-24061 (aussi scorée 9.8), avait déjà été divulguée. Et celle-là, la CISA l’a depuis ajoutée à son catalogue de vulnérabilités activement exploitées dans la nature. Ça me rappelle carrément
la faille RCE dans cups-browsed
l’an dernier… Ces vieux services réseau, c’est dingue comme ça revient régulièrement.
Donc gaffe à vous parce que si vous avez du telnetd qui traîne quelque part (serveurs Debian, switchs Cisco, automates Siemens, imprimantes HP réseau…), faut agir vite.
Déjà, désactivez le service avec un
systemctl stop telnet.socket && systemctl disable telnet.socket
ou éditez /etc/xinetd.d/telnet si vous êtes sur un vieux système.
Sinon, on bloque le port 23 avec un
iptables -A INPUT -p tcp --dport 23 -j DROP
… plutôt que de laisser ça ouvert aux quatre vents. Isolez aussi l’accès via un VLAN dédié aux seuls réseaux autorisés et faites tourner le daemon sans les privilèges root si votre config le permet. Et en couche supplémentaire, je vous recommande le
port knocking
qui permet de masquer vos ports aux scans automatiques (ça ne corrige pas la faille, mais ça réduit la surface d’exposition).
Par contre, le problème vous l’aurez compris, c’est que beaucoup de ces équipements ne supportent pas forcément SSH. Donc y’a encore des tonnes et des tonnes de switchs managés et d’automates industriels coincés sur telnet parce que le constructeur n’a jamais jugé bon de supporter autre chose.
Et dans ces cas-là, le seul vrai plan de secours finalement, c’est ce bon vieux firewall et un peu d’isolation réseau. C’est pas l’idéal, mais c’est toujours mieux que rien.
Bref, bloquez le port 23 et passez à SSH. C’est quand même pas compliqué, meuuuuh !!
Source : korben.info