Re: Local Privilege Escalation via telnetd debug_open() and printsub()

Guillem Jover <[email protected]> writes:

> On Tue, 2026-03-17 at 05:15:58 +0200, Justin Swartz wrote:
>> 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
>>=20
>> The first issue involves a hardcoded filename for the debug log
>> initiated by telnetd/utility.c's debug_open():
>>=20
>> static int
>> debug_open (void)
>> {
>>   int um =3D umask (077);
>>   if (!debug_fp)
>>     debug_fp =3D fopen ("/tmp/telnet.debug", "a");
>>   umask (um);
>>   return debug_fp =3D=3D NULL;
>> }
>>=20
>> Relying on a predictable filename in a world-writable directory
>> such as /tmp opens the door to symbolic link attacks.
>>=20
>> 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.
>>=20
>> 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.
>
> While preparing a Debian inetutils revision to fix all the remaining
> publicly reported security issues, I stumbled into what seems like a
> worse problem from the described root cause.
>
> A user can pre-create the file, and then keep a read file descriptor
> to snoop any on-wire credentials. The changes in
> <https://codeberg.org/inetutils/inetutils/pulls/20> do not help
> because even changing the permissions (and the ownership which the PR
> does not do), is not effective for an already open file descriptor.

Right, nice catch.

>> POTENTIAL MITIGATION
>>=20
>> While this sort of symbolic link attack in a sticky directory is
>> usually mitigated by default on many Linux distributions that have=20
>> fs.protected_symlinks=3D1 in their sysctl configuration, it's unwise
>> to rely on operating system controls to mask defective application
>> logic.
>
> The problem above also affects Linux on its default configuration. I
> guess it could be mitigated by creating an empty file owned by root
> with 0600 permissions, at boot time (although I'd find that annoying
> and my first reaction would be to assume it was a leftover file from
> the daemon which didn't clean properly).
>
> I don't think the proposal to dump the entire protocol into syslog
> seem like a great idea either, which would require substantial
> sanitization. Instead for Debian I went with a relatively simple
> change from using =C2=AB/tmp/telnet-debug=C2=BB to =C2=AB/run/telnet/debu=
g.<PID>=C2=BB,
> and made telnetd print the pathname used on the telnet session.
>
> I suppose an alternative could be to let the telnetd user specify a
> filename to use. But the /run switch seems good enough to me.

I don't like the syslog idea either.

I kind of feel like the option should just be removed. I can't find any
users of 'telnetd --debug' or 'telnetd -D' on GitHub or Debian code
search. If someone needs to debug telnet Wireshark is available pretty
much everywhere.

Collin