Justin Swartz <[email protected]> writes: > Greetings, > > I've identified two bugs in the debugging support provided by > telnetd that may be combined to achieve local privilege escalation > or arbitrary file corruption. > > > INSECURE TEMPORARY FILE CREATION > > The first issue involves a hardcoded filename for the debug log > initiated by telnetd/utility.c's debug_open(): > > static int > debug_open (void) > { > int um = umask (077); > if (!debug_fp) > debug_fp = fopen ("/tmp/telnet.debug", "a"); > umask (um); > return debug_fp == NULL; > } > > Relying on a predictable filename in a world-writable directory > such as /tmp opens the door to symbolic link attacks. > > Assuming the file doesn't already exist, any unprivileged user can > pre-emptively create a symbolic link named "/tmp/telnet.debug" and > point it at a sensitive file owned by root, or whoever else might > be responsible for spawning telnetd. > > If telnetd is executed with the -D flag, to enable debugging support, > the daemon will blindly follow the symbolic link and append debugging > output to whatever "/tmp/telnet.debug" points at. > > > UNSANITIZED DEBUG OUTPUT > > The second issue is telnetd/utility.c's printsub()'s lack of debug > output sanitization. This means that line-feed characters received > during suboption negotiation are written directly to the debug log. > > The ability to inject line-feeds significantly maximizes the impact > of appending arbitrary data to sensitive files. > > Programs such as crond, sshd and PAM are typically robust enough to > ignore irrelevant lines, due to invalid syntax or illogical content, > and focus only on lines that appear to be valid configuration in > their respective contexts.
The lack of sanitization is fine. It is only a problem when combined with the incorrect behavior of that link being followed. I submitted a pull request to address that [1]. Thanks, Collin [1] https://codeberg.org/inetutils/inetutils/pulls/20
