The Day the Telnet Died

  1. TELNET is an IETF-standard protocol defined by RFCs.
  2. Telnet is a well-known port assigned by the IANA (tcp/23).
  3. telnet is a client program, originated on Unix, available on many systems, and likely from a quite homogeneous codebase.
  4. telnetd is a server program, also originated on Unix for the purpose of implementing Telnet protocol as a login server. Also a homogeneous codebase or two.

TFA is about items 2 and 4, and 1/3 are completely unrelated.

IIRC, the only traffic that was monitored and detected here is the scanning. The vulnerability scanners that try and detect, for better or worse, what someone's running on port 23, fingerprint it, and figure out if it's a vulnerability.

Interestingly, filtering port 23 only mitigates the CVE by happenstance. It is merely by convention that telnetd runs on port 23, so that people can use it to log in remotely. There is no constraint that requires port 23. Any other service could usurp 23/tcp for itself if the admin decrees it. So, filtering port 23 is an effective mitigation for the defaults of someone running a vulnerable server on the standard port. But it is not a panacea, and it doesn't prevent anyone from using the telnetd server, or the telnet client, except for port 23.

But it also prevents you from offering any service on port 23/tcp, lest it be filtered. You wouldn't want to run a web server, sshd, a MUD, or anything else, because your connectivity would be negatively impacted for this reason. (The common experience is that a lot of Windows SMB/NetBIOS ports are blocked, and SMTP and port 80, on a lot of consumer ISPs, although this is contrasting the ISP situation to Tier-1 transit carriers now.)

How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)?

The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.

Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.

Well, I mean, the first part is a song by Don McLean called American Pie. You might know that, unsure that everyone will pick it out though.

One of the most famous play choices at karaoke bars these days too. I think because the song is a long story, of sorts? But it's a terribly long song and I will leave to take a smoke break anytime it gets chosen. You're going to be there for a good 10 minutes before it concludes.

So maybe the AI prompt was something like, "take CVE-2026-24061 and compose a song lyric in the style of American Pie by Don Mclean". I wonder if you would get similar results with that prompt.

What an amazing bug. I probably spent my first 10 years on the internet just using telnet. They were wild times. You could log ethernet traffic and see passwords. Towards the end of those we started to have a few more single-user machines, but the vast majority were old school many many user machines, where "root" was thought to be tightly restricted (of course, even then, in practice it wasn't if you were in the know).

Anyway, just wild seeing this:

> telnet -l 'root -f' server.test

or

> USER='-f root' telnet -a server.test

Survive 11 years.

An RCE in GNU's telnetd has no relationship to the sunsetting of telnet. Something could equally likely happen with SSH (but not really because the OpenBSD folks are paranoid by nature).

Apple removing the telnet client from OS X was a stupid move. How can you call yourself UNIX and not have a telnet client? It's like removing grep or ed.