Una vulnerabilidad recientemente confirmada en el demonio telnet (telnetd) de GNU Inetutils ha revivido un fallo de seguridad de 27 años, permitiendo a los atacantes obtener acceso root al explotar una sanitización incorrecta de variables de entorno, sin necesidad de autenticación. Registrada como CVE-2026-24061, la falla existe en GNU Inetutils hasta la versión 2.7 e permite eludir la autenticación remota

Una vulnerabilidad recientemente confirmada en el demonio telnet (telnetd) de GNU Inetutils ha revivido un fallo de seguridad de 27 años, permitiendo a los atacantes obtener acceso root al explotar una sanitización incorrecta de variables de entorno, sin necesidad de autenticación.

Registrada como CVE-2026-24061, la vulnerabilidad existe en GNU Inetutils hasta la versión 2.7 y permite eludir la autenticación remota cuando un cliente malicioso proporciona "-f root" como valor para la variable de entorno USER.

Este descubrimiento, reportado por el investigador de seguridad Ron Ben Yizhak, impulsó una investigación más profunda sobre si el fantasma de CVE-1999-0073, una vulnerabilidad de 1999 que permitía a los atacantes inyectar variables de entorno como LD_LIBRARY_PATH para subvertir bibliotecas del sistema, aún acechaba en las implementaciones modernas de telnet.

El problema central radica en cómo telnetd lanza /bin/login. Dado que ambos procesos se ejecutan en un contexto root-to-root, el kernel de Linux establece AT_SECURE en 0 en el vector auxiliar del proceso.

Este valor es crítico cuando es positivo: AT_SECURE indica al enlazador dinámico (ld-linux.so) y a glibc que entren en modo de ejecución segura, lo que descarta o neutraliza automáticamente variables de entorno peligrosas como LD_LIBRARY_PATH, GCONV_PATH y otras.

Con AT_SECURE en cero, el enlazador dinámico trata la sesión como completamente confiable, lo que significa que toda variable de entorno enviada por un cliente telnet es aceptada sin restricciones. Esto traslada la responsabilidad de la sanitización por completo a telnetd, una tarea que no cumple adecuadamente.

Aunque un commit reciente (4db2f19f) introdujo unsetenv("CREDENTIALS_DIRECTORY") para abordar parte del problema, la solución sigue siendo peligrosamente incompleta. Actualmente, telnetd intenta bloquear variables dañinas usando un enfoque de lista negra, filtrando por prefijo o nombre completo de la variable. Los investigadores han confirmado que esto es insuficiente.

Un atacante puede inyectar variables específicas de GNU gettext como OUTPUT_CHARSET y LANGUAGE, junto con la variable de glibc GCONV_PATH, directamente a través del protocolo telnet. Al declarar un desajuste de conjunto de caracteres (por ejemplo, inyectando ISO-8859-1 en un sistema UTF-8), el atacante engaña a gettext para que llame a iconv_open().

Dado que AT_SECURE es 0, iconv_open() sigue ciegamente la ruta GCONV_PATH proporcionada por el atacante para localizar un archivo gconv-modules personalizado —y desde allí, carga objetos compartidos arbitrarios como root.

Prueba de concepto de la vulnerabilidad de telnet de 27 años

En una prueba de concepto demostrada por Justin Swartz, un usuario local con bajos privilegios (abuser) inyectó variables de entorno a través de una sesión telnet estándar para cargar una biblioteca compartida maliciosa (libcash2trash.so).

Cuando /bin/login intentó mostrar un mensaje localizado, gettext activó la cadena de explotación. La carga útil se ejecutó silenciosamente antes de que la conexión se cerrara —copiando /bin/sh con permisos SUID/SGID.

El binario resultante se ejecutó con euid=0 (root) y egid=0 (root), otorgando privilegios root completos al usuario sin privilegios. No se realizó ni requirió autenticación en telnetd.

Los investigadores sugieren consolidar un único CVE para "Sanitización incorrecta de variables de entorno en telnetd" que cubra tanto el vector CREDENTIALS_DIRECTORY como esta fuga del enlazador dinámico de manera integral.

La solución recomendada se aleja por completo del modelo de lista negra defectuoso. Siguiendo el enfoque de OpenSSH AcceptEnv, construir una lista blanca estricta de nombres de variables de entorno seguras para /bin/login, junto con una sanitización rigurosa de sus valores, se considera la única solución confiable a largo plazo.

Se insta a las organizaciones que aún ejecutan servicios telnet a desactivar telnetd inmediatamente y migrar a SSH. Cuando no se pueda evitar el uso de telnet, es esencial actualizar GNU Inetutils y aplicar controles de acceso estrictos a nivel de red hasta que se publique un parche integral.