Remote authentication bypass in telnetd

[Posted January 20, 2026 by corbet]

One would assume that most LWN readers stopped running network-accessible telnet services some number of decades ago. For the rest of you, this security advisory from Simon Josefsson is worthy of note:

The telnetd server invokes /usr/bin/login (normally running as root) passing the value of the USER environment variable received from the client as the last parameter.
If the client supplies a carefully crafted USER environment value being the string "-f root", and passes the telnet(1) -a or --login parameter to send this USER environment to the server, the client will be automatically logged in as root bypassing normal authentication processes.

to post comments

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 20, 2026 22:13 UTC (Tue) by dcantrell (subscriber, #75800) [Link] (3 responses)

This one and the Solaris one from 2007 read the same, even noting that Solaris' telnet bug in 2007 reads like a Linux and AIX rlogin bug from 1994.

https://www.kb.cert.org/vuls/id/881872
https://it.slashdot.org/story/07/02/12/1118248/solaris-te...

I could not find where LWN posted about the story. Wayback Machine can be used to dig up the blogs.sun.com posts and other things.

What was interesting in 2007 was that Sun was in the middle of OpenSolaris being a thing so all of the code was open[-ish] at the time too. So when the vulnerability was announced, everyone could go and look at the code. Sun did some PR work on blogs.sun.com and elsewhere to show how quickly the coordinated working up a fix, testing it, and getting updates out to customers. What we didn't get from that was that, hey, maybe all the other OSes should check their telnet code. Oh well.

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 20, 2026 22:58 UTC (Tue) by edmonds42 (guest, #42670) [Link] (2 responses)

> What we didn't get from that was that, hey, maybe all the other OSes should check their telnet code.

We wouldn't have found this particular inetutils bug if we had gone looking in 2007, though, because it wasn't introduced until 2015, alarmingly enough.

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 20, 2026 23:57 UTC (Tue) by dcantrell (subscriber, #75800) [Link]

True, but too bad inetutils couldn't inherit Sun's fix. It's like all new telnet offerings have to start from that original implementation.

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 22, 2026 4:22 UTC (Thu) by smurf (subscriber, #17840) [Link]

No, but whoever introduced the problem might have remembered not to use unvetted data as arguments in the first place.

Ultimately the problem is that, inside telnetd, the output of the code that processes the template for the arguments to /bin/login is a new string which is then split … instead of a proper argv vector. The current patch includes a nice little blacklist of possible shell metacharacters (ASCII only of course, and not excluding control characters (other than tab and newline)) to paper over the problem, but I hesitate to call that a solution.

Better idea: blacklist the whole inetutils-telnetd package.

That brings some memories!

Posted Jan 21, 2026 12:57 UTC (Wed) by trambox (guest, #181961) [Link]

I remember when something like rlogin localhost -l -froot was suddenly a thing :) That must have been in the 90s.

Really funny

Posted Jan 22, 2026 3:55 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (2 responses)

That's really funny, because for a long time I had been keeping telnet and rsh running on my local machines because they were convenient and fast. And I remember being shocked when an update to telnet + telnetd allowed to directly pass the username to login(1). This immediately made me want to test if mine was affected by the good old rsh -l -froot from the 90s that I had been using when I was a student, and it was not (I don't remember if it was safe or if it didn't support it yet). It's just that I had been too impatient and needed to wait for the bug to finally come by itself :-) It was well before 2015, I'd say 2009 or 2010 max since it's about when I stopped using that machine as a local server. It's fun how history repeats itself!

There's hardly anything more dangerous than composing a command line by concatenating string elements delimited by spaces, some of which are attacker-controlled. There's almost no way to guarantee no extra argument may be injected in this. Yet it's done in a daemon that's supposed to be used to connect to a machine over the network... And since it's rarely used these days, almost nobody cares to check if anything changed in that code, because surely, "good old telnetd is known for being unbreakable".

Really funny

Posted Jan 22, 2026 7:24 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I wanted the speed of rsh or telnet on my 386SX, for connecting over the local network, but I knew that the code was of poor quality compared to ssh, so I patched ssh to add a “none” cipher for unencrypted communication.

Really funny

Posted Jan 27, 2026 3:20 UTC (Tue) by gdt (subscriber, #6284) [Link]

SSH with no encryption is popular for high-speed long-distance file transfers in some science disciplines. These large transfers are typically of science sensor output, which for Big Science is random-appearing data until it is crunched by some $millions of supercomputer into a fuzzy pixel. Whilst the data is not encrypted, the sensor output does meet some attributes of encrypted data.

To avoid serious user error, the OpenSSH project won't upstream a 'none' encryption option, so a fork of PortableSSH is maintained at github.com/rapier1/hpn-ssh.