Une vulnérabilité Telnet ouvre la porte à l’exécution de code à distance en tant que root

Lucas Morel

La faille dans une implémentation Telnet existante permet l’exécution de code à distance de pré-autorisation, exposant les systèmes concernés à une compromission totale.

Une vulnérabilité Telnet critique avec un indice CVSS de 9,8 permet aux attaquants de prendre le contrôle total des systèmes concernés avant même que l’authentification ne démarre, ont averti les chercheurs en sécurité de Dream Security.

Suivie comme CVE-2026-32746, la vulnérabilité se trouve dans GNU inetutils telnetd, une implémentation largement déployée du protocole d’accès à distance Telnet présent dans les infrastructures existantes, les équipements réseau et les systèmes embarqués. Le protocole a été largement remplacé par SSH (Secure Shell) dans les environnements modernes depuis le début des années 2000.

Dans les systèmes qui exécutent toujours le service Telnet vulnérable, la faille récemment révélée permet une écriture hors limites résultant d’un problème de dépassement de tampon, ce qui peut permettre l’exécution de code à distance (RCE) non authentifié en tant que root.

La cause première est un débordement de tampon dans le gestionnaire telnetd LINEMODE Set Local Characters (SLC) déclenché lors de la négociation du protocole Telnet, selon l’entrée de la National Vulnerability Database pour la faille. La vulnérabilité pouvant être exploitée avant l’authentification, les attaquants peuvent exécuter du code arbitraire immédiatement après avoir établi une connexion à l’aide de messages spécialement conçus.

Dans de nombreux déploiements, telnetd fonctionne avec les privilèges root, ce qui signifie qu’une exploitation réussie peut entraîner une compromission complète du système, a déclaré Dream.

Dream a informé les responsables de GNU Inetutils de la faille le 11 mars, décrivant comment le débordement de tampon pourrait être exploité.

« La réponse SLC est construite dans un tampon fixe de 108 octets, slcbuf, avec seulement 104 octets utilisés pour les données après un en-tête de 4 octets. La fonction add_slc() (lignes 162-175) ajoute 3 octets par triplet SLC mais ne vérifie jamais si le tampon est plein. Le pointeur slcptr est simplement incrémenté à chaque fois », a déclaré la société aux responsables, selon un message adressé à un GNU. liste de diffusion.

« Après environ 35 triplets (…), l’espace de 104 octets est dépassé et le code écrit après la fin de slcbuf. Cela corrompt tout ce qui se trouve après dans BSS (y compris le pointeur slcptr). Plus tard, end_slc() utilise le slcptr corrompu pour écrire le marqueur de fin de sous-option, ce qui donne à l’attaquant une écriture arbitraire en mémoire. Le bug est donc un débordement de tampon classique sans vérification de limites », poursuit le message.

Les responsables ont préparé un correctif le lendemain, prévoyant de le publier d’ici le 1er avril, selon le calendrier indiqué dans l’avis de Dream.

Les systèmes vulnérables incluent les systèmes embarqués et les appareils IoT avec une interface Telnet exposée ; les serveurs et les appareils qui écoutent sur le port TCP 23 et utilisent la base de code vulnérable, ainsi que les distributions Linux qui fournissent inetutils et laissent telnetd activé ou installable, notamment Debian, Ubutnu, RHEL et SUSE, a déclaré Dream.

« Une seule connexion réseau au port 23 suffit pour déclencher la vulnérabilité. Aucune information d’identification, aucune interaction de l’utilisateur et aucune position particulière sur le réseau ne sont requises », indique-t-il.

Dream a conseillé un certain nombre de solutions immédiates jusqu’à ce que le logiciel puisse être corrigé, notamment la migration vers des alternatives sécurisées telles que SSH et la désactivation de telnetd ou son exécution sans privilèges root. Lorsque cela n’est pas possible, il est conseillé de bloquer le port 23 au niveau du périmètre du réseau et de limiter son utilisation aux hôtes de confiance.

Il s’agit de la deuxième faille liée à Telnet à apparaître cette année, après la découverte en janvier d’un bug de contournement d’authentification qui exposait les appareils à une prise de contrôle complète.

Sécurité du réseauSécurité