27 Years old Telnet Vulnerability Enables Attackers to Gain Root Access


27 Years old Telnet Enables Attackers Gain Root Access

A newly confirmed vulnerability in the telnet daemon (telnetd) in GNU Inetutils has revived a 27-year-old security flaw, allowing attackers to gain root access by exploiting improper sanitization of environment variables, with no authentication required.

Tracked as CVE-2026-24061, the flaw exists in GNU Inetutils through version 2.7 and enables remote authentication bypass when a malicious client supplies "-f root" as the value for the USER environment variable.

This discovery, reported by security researcher Ron Ben Yizhak, prompted a deeper investigation into whether the ghost of CVE-1999-0073, a 1999 vulnerability allowing attackers to inject environment variables like LD_LIBRARY_PATH to subvert system libraries — still haunted modern telnet implementations.

The core problem lies in how telnetd launches /bin/login. Because both processes run in a root-to-root context, the Linux kernel sets AT_SECURE to 0 in the process’s auxiliary vector.

This value is critical when positive, AT_SECURE signals the dynamic linker (ld-linux.so) and glibc to enter secure-execution mode, which automatically discards or neutralizes dangerous environment variables like LD_LIBRARY_PATHGCONV_PATH, and others.

With AT_SECURE at zero, the dynamic linker treats the session as fully trusted, meaning every environment variable passed by a telnet client is accepted without restriction. This shifts the burden of sanitization entirely onto telnetd itself a responsibility it fails to meet.

google

Although a recent commit (4db2f19f) introduced unsetenv("CREDENTIALS_DIRECTORY") to address part of the problem, the fix remains dangerously incomplete. Telnetd currently attempts to block harmful variables using a blacklist approach, filtering by prefix or full variable name. Researchers have confirmed this is insufficient.

An attacker can inject GNU gettext-specific variables such as OUTPUT_CHARSET and LANGUAGE, alongside the glibc variable GCONV_PATH, directly through the telnet protocol. By declaring a character set mismatch (e.g., injecting ISO-8859-1 against a UTF-8 system), an attacker tricks gettext into calling iconv_open().

Since AT_SECURE is 0, iconv_open() blindly follows the attacker-supplied GCONV_PATH to locate a custom gconv-modules file — and from there, loads arbitrary shared objects as root.

27 Years old Telnet Vulnerability PoC

In a demonstrated proof of concept by Justin Swartz, a low-privileged local user (abuser) injected environment variables through a standard telnet session to load a malicious shared library (libcash2trash.so).

When /bin/login attempted to display a localized prompt, gettext triggered the exploit chain. The payload executed silently before the connection dropped — copying /bin/sh with SUID/SGID permissions.

The resulting binary ran with euid=0 (root) and egid=0 (root), granting full root privileges to the unprivileged user. No telnetd authentication was performed or required.

Researchers suggest consolidating a single CVE for “Improper environment sanitization in telnetd” to cover both the CREDENTIALS_DIRECTORY vector and this dynamic linker escape comprehensively.

The recommended remediation moves away from the flawed blacklist model entirely. Following the OpenSSH AcceptEnv-style approach, building a strict whitelist of safe environment variable names for /bin/login, paired with rigorous input sanitization on their values, is considered the only reliable long-term fix.

Organizations still running telnet services are urged to disable telnetd immediately and migrate to SSH. Where telnet cannot be avoided, upgrading GNU Inetutils and applying strict network-level access controls is essential until a comprehensive patch is released.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.

googlenews



Source link