Re: Re: Telnetd Vulnerability Report

[kf503bla () duck com]

Who uses telnet anyway? It's deprecated. Everyone uses ssh for any kind of remote access.


On Tuesday, February 24th, 2026 at 7:51 AM, Justin Swartz <justin.swartz_at_risingedge.co.za_kf503bla () duck com> 
wrote:

> Greetings,
>
> I have been reviewing the recent vulnerability report by Ron Ben Yizhak regarding CREDENTIALS_DIRECTORY, as well as 
> commit 4db2f19f which introduces unsetenv("CREDENTIALS_DIRECTORY") to address the problem.
>
> After becoming aware of CVE-2026-24061 (telnetd in GNU Inetutils through 2.7 allows remote authentication bypass via 
> a "-f root" value for the USER environment variable), I was curious to find out whether there'd also been a potential 
> regression of CVE-1999-0073, described as: telnet allows a remote client to specify environment variables including 
> LD_LIBRARY_PATH, allowing an attacker to bypass the normal system libraries and gain root access. I can confirm that 
> this is still an issue 27 years later, despite attempts at blacklisting environment variables by prefix or full name.
>
> The problem stems from telnetd executing /bin/login in a root-to-root context, which means that AT_SECURE is set to 0 
> by the kernel in the process's auxiliary vector. When AT_SECURE holds a positive value, it informs the dynamic linker 
> (ld-linux.so) and libc to enter a "secure-execution mode" where a bunch of interesting environment variables are 
> discarded or, at least, defanged if present. In other words, the responsibility is on telnetd itself to ensure that 
> none of those potentially interesting, and attacker controlled, variables make their way to /bin/login.
>
> While using unsetenv() negates a user's ability to exploit the login.noauth vector, the possibility still exists for 
> the inclusion of variables of interest to GNU gettext (such as OUTPUT_CHARSET or LANGUAGE) and glibc (such as 
> GCONV_PATH) via the telnet protocol itself.
>
> For example, by injecting OUTPUT_CHARSET and LANGUAGE, an attacker can persuade gettext that a character set 
> conversion is necessary. This forces gettext to call libc's iconv_open(), and because AT_SECURE is 0, iconv_open() 
> will use an injected GCONV_PATH in its quest for a gconv-modules file. Assuming the attacker already has a local 
> unprivileged account, or at least a means of uploading files to the host (and knowing the location of the uploaded 
> files), a custom gconv-modules file will allow arbitrary shared objects to be loaded soon after /bin/login attempts 
> to print a localized prompt.
>
> For proof of concept, I've declared a broad selection of LANGUAGE codes for the best chance of matching an installed 
> locale. An attacker with local access could simply determine what's actually installed and select only one that 
> doesn't match the system's default locale instead. Similarly, OUTPUT_CHARSET has been chosen as a deliberate mismatch 
> against the very common choice of UTF-8:
>
>   abuser@prospecton.hyperama:~$ ls -al .gconv
>   total 184
>   drwxr-xr-x 2 abuser abuser   4096 Jan  1  1970 .
>   drwxr-x--- 5 abuser abuser  36864 Jan  1  1970 ..
>   -rw-r--r-- 1 abuser abuser    256 Jan  1  1970 gconv-modules
>   -rw-r--r-- 1 abuser abuser  15568 Jan  1  1970 libcash2trash.so
>
>
>   abuser@prospecton.hyperama:~$ telnet -l abuser
>   telnet> environ define GCONV_PATH /home/abuser/.gconv
>   telnet> environ export GCONV_PATH
>   telnet> environ define LANGUAGE fr:de:es:it:pt:nl:sv:pl:uk:ru:zh_CN:ko:ja
>   telnet> environ export LANGUAGE
>   telnet> environ define OUTPUT_CHARSET ISO-8859-1
>   telnet> environ export OUTPUT_CHARSET
>   telnet> open 127.0.0.1
>   Trying 127.0.0.1...
>   Connected to 127.0.0.1.
>   Escape character is '^]'.
>
>   Linux (localhost) (pts/6)
>
>   Connection closed by foreign host.
>
>
>   abuser@prospecton.hyperama:~$ ls -al .gconv
>   total 184
>   drwxr-xr-x 2 abuser abuser   4096 Jan  1  1970 .
>   drwxr-x--- 5 abuser abuser  36864 Jan  1  1970 ..
>   -rw-r--r-- 1 abuser abuser    256 Jan  1  1970 gconv-modules
>   -rw-r--r-- 1 abuser abuser  15568 Jan  1  1970 libcash2trash.so
>   -rwsr-sr-x 1 root   root   125640 Jan  1  1970 trash
>
>
>   abuser@prospecton.hyperama:~$ .gconv/trash -p
>   # id
>   uid=1001(abuser) gid=1002(abuser) euid=0(root) egid=0(root) groups=0(root),1002(abuser)
>
>
> Once the telnet connection opens, /bin/login tries to print the localized prompt but gettext recognizes the encoding 
> mismatch and calls iconv_open() to parse the gconv-modules file in the directory referenced by the injected path 
> before loading the shared object that turns cash ($) to trash (#). The connection drops because I included a call to 
> exit() once the payload has executed. As illustrated above, the payload effectively asserts root privilege and makes 
> a copy of /bin/sh with SUID/SGID permissions. Note that no authentication via telnetd was required, nor performed, 
> for this privilege escalation trick to occur. Also note that this is just one of many possible methods that may be 
> used to exploit this condition.
>
> In my opinion, to fix this issue and finally put the ghost of CVE-1999-0073 to rest: telnetd must drop the blacklist 
> approach and adopt the OpenSSH AcceptEnv-style approach suggested by Simon Josefsson [1], which amounts to preparing 
> a brand new environment for /bin/login based on a strict whitelist of variables names considered to be "safe", and 
> perhaps a healthy dose of input sanitization for their respective values.
>
> In terms of the CVE that Ron Ben Yizhak had asked about earlier in the thread: I think it might make the most sense 
> to co-ordinate a single CVE for "Improper environment sanitization in telnetd" that comprehensively covers both the 
> CREDENTIALS_DIRECTORY vector and this dynamic linker escape.
>
> I'm happy to share the intentionally redacted payload privately with the maintainers should any help be required to 
> reproduce the proof of concept.
>
> Regards,
> Justin
>
> ---
>
> [1] https://lists.gnu.org/archive/html/bug-inetutils/2026-02/msg00002.html