hckrnws

Never mind telnetd. Tier 1 transit providers doing port filtering is EXTREMELY alarming. They have partitioned the Internet, and in a way that automatic routing (BGP) can't get around.

> Tier 1 transit providers doing port filtering is EXTREMELY alarming.

I was admining a small ISP when blaster and its variants hit. Port filtering 139 and the rest was the easiest way to deal with it, and almost over night most of the ISPs blocked it, and we were better for it. There was a time when if you'd put a fresh XP install on the Internet you'd get 5-10 minutes until it would get restarted.

I guess if you're really an admin that needs telnet, you can move it to another port and go around it? Surely you'd tunnel that "old box that needs to stay alive" if that's the usecase? Is there anyone seriously running default telnet on 23 and is really affected by this filtering?

Lots of text games - MUDs - still play over telnet using dedicated MUD clients that implement their own telnet stack. Outright blocking the port has an outsized side efffe on them, this is simply not right.

Hosted roguelikes have been using ssh for at least 15 years. It's probably time for MUD folks to consider this.

[dead]

If MUDs and other games were indeed using port 23/tcp for player access, they were not only incorrect but rather dangerous.

Since 23/tcp is a well-known IANA-registered port for the Telnet service, it is an RFC violation to use it for a service that is not telnetd/remote logins via TELNET protocol.

Any port below 1024 signifies that it is a "privileged port". This is an archaic distinction that developed in high-trust R&E networks, but it did signify that the listener on the port had administrative/root access to spawn a service there, so it was kind of a signal that you could "trust" the remote server with your login credentials.

The privileged ports were also priority, because if the unprivileged ones were "first come, first served" for unprivileged users, the administrator would have the ability to enforce the uniqueness of "privileged ports", and disable or kill any process that shouldn't be using one. A MUD Wizard who finds their port in-use (bound) on start is on their own.

Typically there were no MUDs running with, or needing, root privileges. They were run under user accounts, or specific unprivileged role accounts. They had no need of a privileged port, and many were clandestine or unauthorized, and forced to use a higher port number. That's why the 4-digit ports became so popular.

Anyway, the custom has already developed of blocking port 23 to protect users from unwittingly opening a management or login interface. Most shrewd admins would choose a port that isn't routinely blocked and filtered... and port-scanned.

If your favorite MUD runs on port 23 today, such as nethack or something, then I am glad for this change, which will force the administrator to select a unique port that does not imply privilege, TELNET protocol, or shell login credentials. It is totally RFC-compliant to select an unassigned port above 1023, and MUD conventions have popularized several numbers that are still recognizable to players today.

They're remote terminal applications? Remote interactive text sessions. Over TELetype NETworking?

You're saying that connecting my tty (emulator), to a remote host is not the purpose of telnet?

<backs away slowly>

Though ... I suppose by now a switch to port 22 could make sense.

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers.

The end of RFC854, the very last paragraph, states:

https://datatracker.ietf.org/doc/html/rfc854

   Port Assignment

      When used for remote user access to service hosts (i.e., remote
      terminal access) this protocol is assigned server port 23
      (27 octal).  That is L=23.

A MUD game could never be confused with managing the server where it runs, or a user/admin login to access that operating system. A MUD game has a specific purpose of recreation/leisure/communication.

Again, let us not conflate port 23 with telnetd with the TELNET protocol. These are all completely separate and distinct. Except that port 23/tcp implies TELNET protocol and also implies a telnetd-type server. It is sort of a one-way chain of requirement. telnetd could be run on any port (inadvisable) while TELNET protocol could be implemented by any other service (often preferable).

A MUD server is perfectly entitled to use TELNET protocol! In my server-hacking days, I often considered it a mistake and error not to support TELNET protocol! If I had known how to implement it, I would've added it to TinyMUCK myself! Honestly, it was not a priority because there was no known client supporting TELNET, either. Of course, protocol support needs to be on both ends to be effective. Without demand or capability from clients, it didn't really make sense for server programmers to add it in.

But we were perfectly content to stay on port 2283, port 4201, or port 6250, as our players and Wizards had established the games to run there, especially in those days we wished to escape notice by admins. The TELNET protocol can run on any port and support any "network virtual terminal" service. But the "telnet port" on 23 is special, unique, and as of last month, really inadvisable for everyone.

> A MUD game could never be confused with managing the server where it runs

What do you think of [], highlights: It is extremely tightly integrated with the system. Connections are handled by telnetd, and the interface is basically considered a shell by the system. MUD characters are treated as actual users by the system, with a UNIX username consisting of "m-" followed by the first 5 characters of their selected character name. The database is stored as directories and files, with occasional symlinks.

Any programming or scripting language which is capable of manipulating Mooix's data files can be used to write custom commands, in a similar idea to, say, CGI. Libraries have been created to aid in this for several languages, including Perl, C, Ruby, and bash.

When a character is enabled as a programmer, they basically get the amount of power normally associated with a shell account. They can create and execute files, evaluate perl scripts, and can access a simplified version of a standard UNIX shell, among other benefits. Facilities are provided to edit Mooix scripts or programs (using your favorite editor) from within the MUD, then set them up to be executed when a user types a certain command.

[]https://everything2.com/title/Mooix

Well that's unique!

It is a horse of a different color when user logins are handled by telnetd itself. I would imagine that access could also be provided by ssh. I know of no MUD that supports MFA, public/private keys, and host certificates!

At any rate, as of January 2026, Mooix users are gonna have a tough time connecting on port 23/tcp. I won't say they've been wrong for using it until now, but they may find themselves forced to switch to ssh, or at least a 4-digit port number. And patch that GNU telnetd ASAP, man.

EDIT: Sad to say, please do not visit the website cited in this linked article. It is, how you say, squatted by purveyors of smut. It may be the case that Mooix is abandonware.

I don't understand how playing a MUD doesn't fit the definition of "remote user access to service hosts".

> by longstanding convention, that port 23/tcp is given to telnetd type login servers

First thing I ever telnetted to was Melvyl, University of California's library catalogue, around 1985. This was “remote user access” (I was a remote user) to “service hosts” (running the catalogue) providing “remote terminal access”. It was not a login.

I remember using MELVYL too, and you're completely right about that.

I would suggest that MELVYL on port 23/tcp was also unnecessarily impinging on the IETF standards. MELVYL could have easily established its own well-known port with the IANA and not conflicted with the TELNET login port.

Before the WWW, there were a multiplicity of search services and indexes. Remember Archie, WAIS, and Gopher? Apparently, WAIS was assigned port 210/tcp, but Archie apparently used TELNET on 23/tcp as well.

I think some of the pioneering Internet services were perceived as not requiring a dedicated port. If MELVYL was the only service running on the mainframe and it wasn't running a Unix telnetd, then why not usurp 23/tcp? The admins there probably perceived it as a virtual "octopus cable" connecting remote "terminal labs", and for sure they had alternate methods of access for OS servicing and configuration purposes. In the beginning of MELVYL they were undecided about which protocol would prevail, and TCP/IP was competing with others, so port numbers may have been afterthoughts for the architects.

The most important thing may have been the principle of not surprising users or confusing them with parameters. "telnetting to a host" was way easier without trying to specify that they needed a port number. Just ask any Unix admin where MUD users try to bang on their telnetd port trying to play the game...

The vast majority of MUDs don't even implement the full TELNET protocol, just a small subset. In typical MUD fashion, fundamental TELNET parts like option negotiation were either hacked together -badly- or altogether ignored.

For the longest time in the 90s TELNET AYT would crash tons of custom implementations.

Boy, wait until I tell you what happened with http!

Exactly the same thing? Are you taunting me with some kind of ignorance? Again, you've introduced ambiguity and we can't tell if you are referring to a protocol, or a port.

https has the special property of working on any port and didn't need to switch to 443. You could run https servers on port 80. Both of them are considered "privileged".

Plenty of http and https servers alike on unprivileged ports too. Ports 80 and 443 were more about exclusivity and well-known assignments, than trust.

The unique thing about HTTP the protocol is that it came to be implemented by practically everything, as in REST and web apps. It's an Internet lingua franca.

TELNET protocol was severely neglected, which is why I was surprised that MUDs kept it alive!

To sibling: A MUD character is not a user. A user is a user who logs into user accounts, e.g. shells. You could read it as "a host providing a service" to someone, I suppose, but again, in longstanding practice, 23/tcp was reserved to telnetd and other management/shell logins, not some kind of generic "interactive NVT anything goes" service. "Remote terminal access" was understood universally as like a console, or tty, that would invariably present a shell login, not Zork or Colossal Cave!

You mean something like this?

     mudplayer:x:1001:1001:MUD Player:/home/mudplayer:/usr/games/adventure

[flagged]

Their replies are only obtuse because you fail to see that you’re being made fun of for having such a ridiculous pedantic position about this. “Terminal” does not mean shell when you read the Telnet RFC. It means TTY. A human to machine interface. MUDs implement the Telnet protocol and provide a remote TTY. What’s running on the terminal is absolutely irrelevant.

It is not pedantic and many respondents are simply obstinately conflating the tcp port with the protocol and with the server software. You have done the same thing. Did you not read my statement where I said it is perfectly fine and even preferable for MUDs to implement TELNET? Where did I ever oppose the implementation of TELNET protocol?

Yes, when the TELNET protocol is in use, the applications are irrelevant to the underlying substrate of an NVT. But when port 23 is in use, everything changes. That is my point. And there seems to be a brigade of mudders who are butthurt about losing their pet TCP port in this. They cannot mock me because they are wrong. Their wizards chose poorly decades ago.

<backs away slowly>

<realizes HN is not a MUD>

<stops emoting like you're a monster uWu>

Can you show the exact line in the RFC or IANA port reservations that says it has to implement a shell login interface with the Telnet protocol if it’s on port 23? Because I can’t find it. Nothing says that anywhere.

I literally already did. And it is not merely the RFC which specifies it. The RFC defines the protocol and really leaves it open-ended for any sort of implementation.

What defines port 23/tcp is the longstanding usage and the original understanding of a "remote terminal" or NVT. In 1983 when the IETF described the NVT, it was simply understood that a terminal, or "canonical console", was a method to access a timesharing system and log in as a user. If you went to a "terminal lab" or you sat down at a desk with a "terminal" or "teletype" or any of its predecessors, you were preparing to log in and do some programming or data processing.

There were literally no terminal labs where you would sit down and begin playing Centipede, Asteroids, or PONG. Those were completely different concepts of "consoles" and "cabinets" and the IETF did not stutter when they defined an NVT.

Every Unix implementation, every router and network device, practically anything with an Internet connection implemented a "shell" login on port 23 or it did not. There were plenty of systems with /usr/games and a plethora of leisure-time activities, but surprisingly they did not default to using port 23/tcp. It has been long-standing tradition, and convention, that the TELNETD service operating on 23/tcp is what a user expects to find when they connect.

MUD admins and wizards who put their servers on 23/tcp necessarily needed another way to log in and manage their server. I am surprised that they were so easily able to usurp telnetd if this was the status quo. Was sshd already established for them or something? Did they just resort to rlogin instead? I'm genuinely clueless and curious how it was so easy to usurp 23/tcp and use it for MUDs.

Because my community often ran them clandestinely, and we always ran them unprivileged, so there would literally be no way for the server to start on port <1024 -- it never ever had root access! If your MUD ran on port 23, that's dangerous because at some point, somewhere, some time, it enjoyed root access, and hopefully dropped that UID 0 immediately after the bind()!

Just for you I will switch my FTP server to run on Port 23.

Data or Control channel?

TCP or UDP or SCTP?

The world's your oyster, man

> Your MUD wizards made a bad, bad choice long ago when they picked port 23.

I'm confused. I refer you to my previous answer. Which does not specify a port, nor does it need to.

:x: can be a PAM database?

It's ... how I'd do it. You get a lot for free.

> Any port below 1024 signifies that it is a "privileged port". This is an archaic distinction that developed in high-trust R&E networks, but it did signify that the listener on the port had administrative/root access to spawn a service there, so it was kind of a signal that you could "trust" the remote server with your login credentials.

If something is running on a privileged port is not enough to trust it. Firstly you need to trust to a host, you need to know where are you connecting to. If you connect to a random host with a privileged port and pass it your credentials you are doing stupid things.

This thing with privileged ports is protecting you from users who could run arbitrary code on a server. From them and not from anyone else. So for MUD there is a lot of reasons to run on 23 port, it is a signal for users of MUD that they are connecting to a process hat was started by the owner of the machine having the root.

> If your favorite MUD runs on port 23 today, such as nethack or something, then I am glad for this change, which will force the administrator to select a unique port that does not imply privilege, TELNET protocol, or shell login credentials. It is totally RFC-compliant to select an unassigned port above 1023, and MUD conventions have popularized several numbers that are still recognizable to players today.

If I was running a MUD, I would find some way to get around. I could use 22 for example, though it could cause me problems with logging in with ssh. But it is not an issue really, there are 1k privileged ports, I could choose one from them.

You have contradicted yourself within your comment. Either a "privileged port" can be trusted or it cannot.

As I implied in my previous comment, "privileged ports" are no longer a signal of trust on Internet hosts. Literally anyone could have administrator access to a host. The MUD could be running on a Raspberry Pi in a guy's basement. A telnetd server could be on port 23 of a personal router. You could telnet into a print server, a washing machine, or a microwave oven.

In a world where devices are cheap, personal, and accessible, anyone could be an administrator of anything.

You say "privileged ports ... protect you from users who could run arbitrary code" which makes no sense, man! Unprivileged users can always run arbitrary code unless they can't! Administrators must be able to run arbitrary code! Why should you be protected from that? If someone cannot run arbitrary code then chances are that they cannot bind a "privileged port" so is that what you meant?

Again, why does a MUD need a privileged port? Why? No reason. The vast majority of "privileged ports" are occupied and assigned. You do not want to use them. You have no reason to use unassigned, privileged ports for a MUD. It is not a question of "trust" or "arbitrary code" or authenticated users -- it's just a dumb game with no effects on the OS or host system, man! It's a virtual system!

I am afraid that MUD gaming has messed with people's minds more than social media. I myself was psychologically damaged by it. I urge you to seek help, before anyone else posts incoherent comments in this thread today.

Yes, and sftp and scp should not operate on port 22 because that isn't proper, interactive SSH!

> it is an RFC violation

I hate to break it to you, but RFC violations power the internet.

Also, RFCs are non-binding and the IANA port numbers are just strongly suggested.

I run a PDP-10 during the colder parts of the year. It's for historical preservation reasons. There are others doing the same thing. We still offer telnet access because that's how it worked back then. I guess we aren't going to be doing that anymore.

If you can get it on IPv6, maybe via a gateway, port 23 filtering doesn't seem to be applied to IPv6 yet! (I assume because the v6 address space is too large to mass scan?)

If I am rewriting the network stack or making other substantial changes, that defeats the purpose of historical preservation.

If moving it to another port from the OS is beyond the pale for you, your router should implement PAT (port translation) or forwarding, so that from the outside, users could connect on, say, 443 or 2323, and the router rewrites the segments to connect to your immutable port 23/tcp.

It makes no sense that IPv6 is treated differently than IPv4. If GNU telnetd is vulnerable and it's running on port 23/tcp, it will be found on IPv6. I would definitely not bind anything to listen on port 23 on any protocol, because I would expect it to become filtered shortly. Port 23 is permanently burned everywhere.

Conversely, a vintage PDP-10 telnetd is not affected by the CVE for GNU.

It is a classic rookie mistake to treat the two protocols differently, so if Tier-1 providers have done this, they must be overly optimistic, or foolish, or met with some technical obstacles, or perhaps OSI Layer 8?

I meant rewriting it for IPv6 instead of IPv4.

The GP's concern isn't a practical one, it's ultimately about net neutrality. It's not the ISP's job to discriminate against traffic—it's their job to deliver it.

This may seem like a good idea, and frankly is likely a net-positive thing, but it is literally the definition of "ISP decides what apps its customers can and cannot use."

I share the concern and don't really like it either.

It's not a net-neutrality issue because they're not banking on any alternative.

Net-neutrality law doesn't work like that. Service providers still get to filter stuff.

What's illegal for an ISP is e.g. to give VoIP services other than their own a lower priority. That would tie in customers to use their own service and they could even charge more for it. Net neutrality means a level playing field for services on the Internet.

If you ask your ISP to do filtering, that's perfectly legal. If they filter specific traffic for the purpose of maintaining service, that's okay too.

Now if there was no alternative and they'd try to sell their product by blocking telnet, they could be sued.

This is not an ISP. It's a Tier 1 transit provider.

The more unlikely they would violate net neutrality unless they would be tied in to CDNs and accept a bribe to favour one service over another.

Possible but unlikely.

My ISP (AT&T) is a tier 1 transit provider.

There is some merit to the end user ISPs doing that - for example one I used before filtered SMTP traffic (and iirc some other) to the client unless you opted out from it.

Which was mildly annoying workaround for the power users (disabling it was just changing the ppp login), but stopped a lot of accidentally open open relays and a lot of other cruft

Changes like these lend even more credibility to the approach of putting everything on port 443 over TLS, and distinguishing protocols based on hostname / HTTP path.

Wireguard over 443/udp is also a neat trick. No need to make it look like quic although I wouldn't be surprised if someone takes the effort to make it that stealthy.

If everything was on port 443 why would we even need ports.

The ports are there for a reason, it is idiotic to serve everything over http as you would need a mechanism to distinguish the different flows of traffic anyhow.

Preventing the traffic from being distinguished is the whole premise. Port 23 gets blocked because everyone uses it for telnet, and everyone expects bad actors to know that. If everything moves to 433, we'll end up with a variety of routing systems and no focal point for attack. The only alternative is to disallow port filtering in core internet infrastructure.

We can either have a standard and accept that bad actors will use it against us, or we can accept the chaos that results from abandoning it.

This simply isn't happening, and we have the data to prove it: https://www.terracenetworks.com/blog/2026-02-11-telnet-routi...

> The sky is not falling.

Great analysis, thank you!

New thread: Reports of Telnet's Death Have Been Greatly Exaggerated https://news.ycombinator.com/item?id=46980355

I do not know what is more critical: the risk of censorship or stand by while hospitals, banking, nuclear power plants and other systems become compromised and go down with people dying because of it. These decision makers not only have powers but also have a responsibility

Have you ever seen a hospital, a bank, a power plan to expose telnetd to the public internet in the last 20 years? It should be extremely rare and should be addressed by company’s IT not by ISPs.

These are the institutions I would most expect to do that.

Well, maybe not a bank.

Probably Tier 1 providers have some insight on this.

This feels more akin to discovering an alarming weakness in the concrete used to build those hospitals, banks and nuclear power plants – and society responding by grounding all flights to make sure people can't get to, and thus overstress, the floors of those hospitals, banks and nuclear power plants.

In the UK we have in fact discovered an alarming weakness in the concrete used to build schools, hospitals and other public building (in one case, the roof of a primary school collapsed without warning). The response was basically "Everybody out now".

https://en.wikipedia.org/wiki/2023_United_Kingdom_reinforced...

https://www.theconstructionindex.co.uk/news/view/raac-crisis...

https://www.theguardian.com/education/2023/aug/31/what-is-ra...

You feel it's similar because having access to port 23 is similarly life critical as having access to an hospital? Or is it because like with ports, when people can't flight to an hospital, they have 65000 other alternative options?

All I'm saying is that the only right place to fix this is at the hospital. Not at the roads leading to it.

That's my question. Why is there infrastructure that has open access to port 23 on the Internet. That shouldn't be a problem that the service provider has to solve, but it should absolutely be illegal for whomever is in charge of managing the service or providing equipment to the people managing the service. That is like selling a car without seatbelts.

We are beyond the point where not putting infrastructure equipment behind a firewall should result in a fine. It's beyond the point that this is negligence.

There again, I think the comparison fails.

Fixing the hospital: single place to work on, easier

Blocking all the roads/flights: everywhere, harder

Vs

Fixing all the telnet: everywhere, harder/impossible

Blocking port 23 on an infra provider: single place, easier

It makes sense to me to favor the realistic solution that actually works vs the unrealistic one which is guaranteed not fix the issue, especially when it's much easier to implement

I run telnetd on 2323 because I don't want hackers to find it.

The hospital-plural-s: many places.

Roads: a lot more places than that.

The core of the analogy holds.

nah, that's like seeing an open gate to nuclear tank - a thing easily fixed within few minutes - and responding to it by removing every road in existence that can bear cars

Censorship is one of these words that get slapped on anything.

Filtering one port is not censorship. Not even close.

> censorship, the suppression or removal of writing, artistic work, etc. that are considered obscene, politically unacceptable, or a threat to security

It is not the responsibility of the Tier 1 or the ISP to configure your server securely, it is their responsibility to deliver the message. Therefore it is an overreach to block it because you might be insecure. What is next. They block the traffic to your website because you run PHP?

Similar to how the mailman is obligated to deliver your letter at address 13 even though he personally might be very superstitious and believe by delivering the mail to that address bad things will happen.

Port 23 has been filtered by most providers for decades.

This is why everything converges on using TLS over 443 or a high port number. I don't see this as a huge deal, and especially not one deserving all caps rants about censorship. Save those for things like FOSTA/SESTA.

Not by tier 1 transit providers. You pay those to deliver your packets, no matter what.

So basically the same as censorship because that is the exact same thing blocking ports does.

I can connect with the GNU telnet client via the Spectrum ISP to servers in both Seattle and the Netherlands.

It doesn’t matter what client you use.

Is it on port 23/tcp, and what are the ASNs?

The report specifically says that cloud networks like VPS, AWS seemed exempt.

not to mention, filtering on udp vs tcp, which makes using anything else impossible. Not that I have one, but it's just a bit in a field, why filter on it?

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.

The more I work in software, the more amazed I am that anything works at all. There's likely so much low hanging fruit out there

I never sent root over telnet, but I spent too much vacation time browsing the web via lynx on my school AIX account from a library near my parents' home, because it had a telnet client in addition to the card catalogue program on the otherwise locked down desktop. It was just a more innocent time: you didn't assume your traffic was being logged six ways to Sunday. With telnet access to my AIX account, I could do all the internet things, like mail (pine) and the web (lynx) and irc, from a convenient command line anywhere in the world.

When did we all stop using telnet? I can't even remember. Most of my first 10-15 years was using telnet. One day I used telnet to connect to a shell for the last time and didn't know it. I had a ton of servers all with root telnet access Internet facing. Never hacked once, somehow. Those were the days.

In the Linux / BSD world, SSH took off incredibly fast for the time. I'd estimate that maybe 80% of people had moved to it within the first year of its release.

But adoption stalled when the original SSH moved to a commercial license in 1996-ish - many of us stuck with the last free version, but vulnerabilities started to pile up. There were various half-working alternatives, but it wasn't until OpenSSH came out in 1999 that the remaining telnet holdouts started to move across.

It was 1996 for me. I forget where the original SSH (SSH1 protocol) came from, but I do remember compiling it on a Slackware box around that time.

I worked for an ISP in the mid-90s and had been on the Internet since 1989 or so. I recall the progression for me was something like this:

We used telnet in college no problem. It was a fairly well-accepted method of remote access. The heterogeneous network had many different modes, but a major dialup point was the Annex box, which supported telnet into the Unix or VMS machines.

Between Unix machines, we would often prefer "rlogin" instead. There were several horrific iterations of other remote-access protocols such as "remsh". rlogin was notorious for its "/etc/hosts.equiv" authorization method which trusted DNS and should've been perceived as Swiss Cheese from the outset. rlogin was, IIRC, directly related to rsh and rcp and used the same frameworks. rlogin was no more secure than telnet, but probably less secure because of its conveniences.

We also used port 23/tcp for remote management, for example Cisco routers. They weren't running telnetd, but it was the port where you connected remotely and logged in with or without credentials.

rlogin persisted alongside telnet, until encryption came into fashion and ssh was distributed. Once ssh was available and working well, everyone knew that telnetd and rlogind were on borrowed time. The services were shut down and disabled in inetd. The ports were sometimes blocked. Security advisories went out.

I suppose it took a long, long time for ssh to finally dominate, and for people to abandon telnetd mostly, but it was fairly thorough. We all recognized the superiority of sshd's authentication and encrypted channels.

There were mitigations for people to extend their legacy use of telnetd and rlogind. For example, tcp wrappers and fail2ban could be implemented. Firewall filters could select only authorized networks. VPNs could tunnel through an Intranet that still used them. So, the services lived on wherever they didn't need to be exposed on the public Internet. But I think most Unix admins got the picture by the end of the dot-com bubble.

> /etc/hosts.equiv

Ah, the memories.

cat '+ +' >> /etc/hosts.equiv

Ah, I have no memory of such a command, so I must be getting old!

It's hilarious, especially given that I have memories of similar rlogin vulnerabilities -- various unixes being vulnerable to rlogin -l '-froot' in the 90s.

Never used telnet to log in to something but it is a cool debugging tool, so used it for that. E.g. can this container even send traffic to that container at all.

I'm a fan of 'nc' / netcat for this purpose. It's small, quick, and can send or receive over TCP or UDP.

So Telnet as a client is not dead though, right? A long time ago, I used to use the Telnet client to talk to SMTP servers (on port 25) and send spoofed emails to friends for fun.

With port blocking widening in scope, I’ve long believed that we would one day have every service and protocol listening on port 443. Since all other ports are being knocked off in the name of security, we’ll end up having one port that makes port based filtering useless.

netcat, socat and openssl s_client are all available for general manual connection testing.

As are many other tools. But the ones above are basically far better direct telnet alternatives.

I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?

Because for a long time, on most computers, the telnet client was the closest thing to an "open a tcp socket to this ip/port and connect the i/o from it to stdin/stdout" application you can get without installing something or coding it up yourself.

These days we have netcat/socat and others, but they're not reliably installed, while telnet used to be generally available because telnetting to another machine was more common.

These days, the answer would be to use a netcat variant. In the past, telnet was the best we could be confident would be there.

In corporate environments, netcat was often banned as it was seen as a "hacking" tool. Having it installed would sometimes get the attention of the security folks, depending how tightly they controlled things.

You don't even need netcat or socat for that, probing /dev/tcp/<host>/<port> from the shell is enough.

That's some gnu bash shenanigans. There is no /dev/tcp in unix

Lots of shops didn't have gnu installed: telnet was what we had.

Telnet was available in the 90s. I reckon /dev/tcp is way more recent. GP did say a long time ago.

Same reason that people use vi. It's always there.

The telnet protocol with escapes, etc. is only used by the telnet client if you’re connecting to the telnet port. If you’re connecting to HTTP, SMTP or something else, the telnet protocol is not enabled.

Because it's there.

It hasn't for the most part of the last 2 decades.

The telnet client comes with MS Windows, Linux and macOS. The only platforms were you need to install some extra component are Android and iOS.

Many companies have been preventing its execution or removing the package by default for a number of years.

Also most linux containers do not ships with such binaries to save on img size and reduce vuln management overhead.

> to save on img size

    $ ls --human --size --dereference $(which telnet)
    144K /usr/bin/telnet

The point is not that this particular binary is huge, the point is that we tend to strip images of anything that is not useful for the actual application shipped. So we strip everything. Also: small things adds up. On AI prompt can be handled reasonably by a single machine, millions of concurrent ones involve huge datacenters and whole energy plants being restarted/built.

The point of reducing the amount of binaries shipped with the image is also to reduce the amount of CVEs/vulns in your reports that wouldn't be relevant for your app but woulld still be raised by their presence.

Telnet client is an optional feature in Windows that needs to be enabled/installed.

telnet hasn’t shipped with macOS since 10.12 Sierra, ten years ago.

Debian also isn’t shipping telnet in the base install since Debian 11.

Thanks, sounds like a recent development. I don't use macOS, but on other peoples macOS computer it was always there, even when they are not developers. But it could very well be that these computers are ten years old.

I mean technically MS Windows 10 is ten years old, but the big upgrade wave to 10 only happened like 4 years ago, which is quite recently. Maybe that is similar to macOS users, I don't know that.

In the days of yore, Windows had telnet installed. Most hackers used telnet in the 90's and early 2000's.

If it's alright to be pedantic, anyone with programming knowledge can do the same without these tools. What these offer is tried and tested secure code for client side needs, clear options and you don't need to hand roll code for.

You can program without tools? I want to see that. Do you still have switches to alter RAM content, or do you use the butterfly method?

who's hand rolling code anymore these days though?

I don’t remember how I did it but when I was about 12 years old I somehow managed to send SMS from Telnet to cell phones, and to the receiver they appeared to be sent by an official Telecom account - good that I was still an innocent child, had I discovered this a few years later I may have tried doing something nefarious with it.

None of this affects the use of telnet the client program nor the ability to run a telnetd on your own host (but do be sure it's patched!).

What's happened is that global routing on the internet (or big chunks of it, it's not really clear) has started blocking telnet's default port to protect presumably-unpatched/unpatchable dinosaur systems from automated attack. So you can no longer (probably) rely on getting to a SMTP server to deliver that spoofed email unless you can do it from its own local environment.

> started blocking telnet's default port

But that's 23 and smtp is 25.

SMTP has and is almost blocked everywhere to dissuade spam.

Presumably not on the SMTP servers they were connecting to. There are millions of IPs with port 25 open, without them email wouldn't work, so I'm not sure what you mean

They probably mean that port 25 is blocked on consumer ISPs/residential IP blocks to prevent malware from running an smtpd on an infected home computer or router (which used to happen a lot), but on a higher level of course no one blocks SMTP.

You would still be able to use the telnet client to connect to an SMTP server on TCP port 25, just not port 23, right? I don't think that part changed here.

It's... not super clear from the article whether this is a port block or a stateful protocol thing. But yes, you're probably right and SMTP spoofing is probably safe for now.

I read it as a clear port 23 block.

Why are people still using telnet across the internet in this century? Was this _all_ attack traffic?

(OK, I know one ancient talker that uses it - but on a very non-standard port so a port 23 block wouldn't be relevant)

To watch Star Wars in ASCII.

telnet towel.blinkenlights.nl https://www.youtube.com/watch?v=Mhcf6tc2jeQ

(Remember hearing about this a long time ago (from some searching I think it was in 1999 via Slashdot) and verified some instance of it still exists/works.)

  Connection failed

It might be the telnet filtering in action. The host responds to ping but I get nothing back on TCP/23, not even a reset.

It's still working over IPv6

213.136.8.188 appears to not respond to telnet from any ISP I attempt to connect to it on, I wonder if its just not bound to port 23 on IPv4 or the ISP is filtering port 23. IPv6 works fine to connect.

~~IIRC the blinkenlights telnet movies have been offline for a few years already.~~

I connected a few times today to the IPv4 one. Have had no problems myself.

Telnet is used in legacy, IoT, embedded, and low-level industrial hardware. It's also intentionally enabled on devices where automation was written for telnet and it wasn't easy to switch to ssh.

If you investigate most commercial uses of ssh, the security is disabled or ignored. Nobody verifies host keys, and with automation where hosts cycle, you basically have to disable verification as there's no easy way around the host keys constantly changing. Without host key verification, there's kinda no point to the rest.

Even assuming the host keys were verified, the popular ssh conventions are to use either long-lived static keys (and almost nobody puts a password on theirs), or a password. Very few people use SSH with 2FA, and almost no-one uses ephemeral keys (OIDC) or certificates (which many people screw up).

So in terms of how people actually use it, SSH is one of the least secure transport methods. You'd be much more secure by using telnet over an HTTPS websocket with OAuth for login.

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.

The manufacturer should at least supply certificates, and it could be up to you to ignore or use. It's not much but it's something.

Unless you manage to leak your private host/client SSH keys, this is close to being as secure as it gets.

I'd say that HTTPS (or TLS in general) is more problematic, since you need to trust numerous root CAs in machine/browser store. Sure, you can use certificate pinning, but that has the same issues as SSH host key verification.

CA compromise is very rare and difficult. There are much easier attacks on TLS than that (notably, attacking insecure validation methods; the problem isn't that CAs aren't secure, it's that validation methods and their dependencies are insecure). Besides, the CAs for TLS only covers transport security; authentication+authorization would be handled securely through OIDC, using temporary sessions and not exposing the true credential, often combined with 2FA. Even you successfully attack a TLS server, two factors, and an active session, it only works once; you have to keep pulling it off to remain inside.

Compare that to malware that just copies a developer's ssh private key off the disk (again, almost nobody ever password protects theirs). This just happened recently on a massive scale with the npm attacks. Or intercepts the first connection from a client host and, again, because nobody ever validates keys, injects a false host key, and now they're pwnd indefinitely. Or, again, companies that do not strictly validate host keys, meaning immediate MitM. There's like a dozen ways to compromise SSH. It doesn't have to be that way, but it is that way, because of how people use it.

> Very few people use SSH with 2FA.

PCI DSS, HIPAA, and ISO 27001 each either highly recommend or enforce this.

I wouldn't use a jumphost without it.

> Nobody verifies host keys,

The known_hosts file is verification of host keys. It's not verification of a host cert, which is a different thing. Most sshd instances are running on ad hoc hardware without the ability to associate them with someone a cert authority would be willing to authenticate.

Basically people running services that need cert-based authentication are already using TLS (or if they're using sshd they've locked it down appropriately). SSH is for your workstation and your RPi and whatnot.

SSH certs aren't TLS certs. Totally different format. All SSH CAs are private, you run your own CA to issue certs to devices you want to allow to connect to your server.

It's... not about the file format.

The point is that a "private" cert is not a "cert" as commonly understood. The important part to a certification authority is the AUTHORITY part, not the data format. Either there is a trusted third party that will promise you are who you say you are, or there is not. With SSH, there is not, nor can there be as it is commonly deployed.

So applications that want that have used other protocols and other schemes, very productively.

>>Nobody verifies host keys,

>The known_hosts file is verification of host keys

I think the point was that those devices typically generate host keys dynamically and therefore the host key verification is usually turned off, leaving you just with encryption (which is still better than telnet - at least you're safe against passive adversaries). At least that's what I've seen in practice.

Host key verification is a client feature and is on by default. Have you really never gotten the giant warning after a reinstall? That's what that is. SSH is telling you that the server has changed and isn't what you think.

I'm saying that 90% of these setups look like this (or do the equivalent thing manually):

   ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168...

Exactly. But 'passive encryption' isn't helpful; if you can see the traffic, you can MITM it. Just RST the connection, wait for the reconnect, intercept.

Well, sure. You can turn off host key checking in ssh! But that isn't responsive to a point that (1) host key validation exists in ssh and (2) host key validation is on by default in ssh.

Their original comment was referring to people ignoring the warning banner and connecting anyway when the host changes. Not that it doesn't exist.

Hams use it over packet radio sometimes since encryption is forbidden on the amateur bands.

IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.

> IMHO we need a good telnet replacement that sends signed data. Most people interpret signatures as allowed under FCC rules, just not encryption.

I know from bitter experience that IPsec is a “now you have two problems” kind of solution, but the Authentication Header is a thing and is supported by most (all?) implementations. Ham radio operators probably don’t have much use for the actual features of telnet compared to plain netcat, do they? (It’s mostly terminal feature negotiation and such.)

TIL that IPsec can be used without encryption. That should work pretty well.

Telnet is mostly used for auth and straightforward terminal/BBS access in my experience. There are some other alternatives like HamSSH but I don’t think it’s that common.

What I meant in my remark about Telnet is that, if you just want is a bidirectional byte pipe to e.g. run a terminal over, then you just need TCP or anything else providing the same abstraction, like TLS-over-TCP or TCP-over-IPsec; whether you then choose to run a getty on that terminal is not for the network to care. (I don’t believe you can get netcat to drive a PTY, so you’ll need e.g. socat. And of course if you want cryptographic authentication then you don’t need or want a getty.)

Telnet, on the other hand, is quite a bit fancier than that and has a fairly involved feature negotiation mechanism for terminal connections that is not entirely in line with the prevalent DEC tradition. As admittedly one of the funkiest examples of what you can do with it, there is for instance a mode[1] where the client is asked to emulate a terminal of the IBM 3270 lineage. (To a practicioner of the aforementioned DEC tradition, those feel like the marsupials of terminals: everything is functionally there, but primitive and derived are occasionally flipped and some features are oddly weak or misdesigned due to a lack of competition.) So if you do actually use Telnet the protocol, by all means, I’ll be delighted to learn what you do with it (partly why I asked in the first place). But if you just need a pipe, then TCP is enough, and netcat or socat make fine ad-hoc clients.

[1] https://tools.ietf.org/html/rfc6270

It’s not so much what I need as what is in common use. Many BBS/terminal stacks for hams haven’t been updated in what seems like decades, except for security updates. It’s tough to get the old guard interested in changing, so they continue to offer their services via Telnet. I’m not sure if what they provide uses any advanced features or not.

You can use ssh with the None cipher, thus disabling encryption entirely while still using the rest of the protocol.

Most people don't care about FCC rules.

I'm breaking a tonne of FCC rules right now.

Yes but in many ways it's riskier to do that when you have a license from them.

In general, this is pretty true in practice.

Just dont mess with: GPS, Airline radio, cell phones, broadcast infra, emergency services

If you're blowing double the power for ISM, nobody cares. Your PEP using a yagi is 4x what is legal? Unless you piss off a ham, nobody cares.

And even if you are a ham, and are using 150KHz bandwidth with low power in, say 50MHz (regulation says 40KHz max), again, nobody cares.

And also if above 6GHz (common SDR top end), nobody will notice. The equipment up there is $$$$$.

But damn, you want to piss off hams? Mention bitrate maximums or encryption. You'll never hear the end from the old gatekeeping idiots.

> But damn, you want to piss off hams? Mention bitrate maximums or encryption. You'll never hear the end from the old gatekeeping idiots.

So much gatekeeping.

Incidentally, I have it Word From On High within Ofcom here in the UK that you literally cannot pay them to take an interest in what happens on the amateur bands.

There's "breaking the law" and there's "being a bit rude", the latter of which might be things like "hey let's do fastscan TV on 70cm and use about half the allocation!" You do have to watch with 70cm in the UK though because amateur radio is a secondary user, with primary users being the armed forces. But it's 10MHz wide and there's space for everyone to play.

Putting the 70cm packet BBS channel 5kHz above where all the car alarm keyfobs work was a bit silly though.

As regards microwave stuff, I've got some scrap 26GHz stuff at work that can apparently be tuned to 24GHz by swapping the cavity tuning screw for one of the slightly longer ODU outer cover screws, and tweaking a setting in the EEPROM in Factory Never Touch This Shit mode. Want to bet they had radio amateurs working for them?

One? All the talkers still use it and all the MUDs/MOOs etc. far out number the talkers.

N.U.T.S. 3.3.3 4eva! There was a NUTS 4, but about a decade too late.

As I understand it, greynoise is monitoring scanner traffic, so yes this would all be scans or attacks

Some of us still run historical systems for preservation's sake.

How else would I connect to my BBS to play L.O.R.D. and check FidoNet.

One reason would be to play MUDs, which are very well and alive these days!

nethack.alt.org still maintains a telnet server!

I've always used ssh to connect to it. And it's true that their port 23 is still open at last check. If you cannot reach port 23, and you irrationally hate ssh, you may use 14321 as an alternate.

https://www.alt.org/nethack/

telnet lambda.moo.mud.org 8888

MUDs were my introduction to telnet- I grew up a university kid and had access to Wesleyan's minicomputer EAGLE.WESLEYAN.EDU running OpenVMS. I used it to telnet to CMU's TinyMUD and later other TinyMUDs around the country. I recall OpenVMS's telnet had a problem with newlines/carriage returns so all the text was staircased, so I ended up learning C and writing a MUD client. I still habitually use telnet today even if netcat and many other tools have replaced it.

All of that was foundational for my career and I still look back fondly on the technology of the time, which tended to be fairly "open" to exploration by curious-minded teenagers.

For a few weeks I ran a MUD over AX.25 for a couple of my friends.

Because on their own, MUDs aren't nerdy enough, amateur radio isn't nerdy enough, and indeed packet radio isn't nerdy enough.

Eventually we decided we'd had our fun and now I needed to the TNC for something else.

Ah, my grandfather was a ham (N4MDB) and he always tried to get me interested in it, but I had to tell him I preferred the internet (this was late 80's, so few people actually had internet). Later when I read Stevens networking books I learned there was a whole Hawaii-based packet radio (ALOHAnet) , and the UC campuses had intercampus microwave networking for a while as well. I actually still remember him telling me about bouncing radio waves off the atmosphere which seemed like magic to me at the time.

Probably one of the reasons this bug survived so long is that it isn't used much for priveleged access any more, but so you can play a moo or play you an ASCII movie, as people below you are replying.

Aardwolf works well from my work laptop. And I don’t care if someone sees what I’m doing

Do you care if they steal your account though and drop all your inventory?

The problem is the auth is plain text too and you're open to having your credentials stolen.

TBH, I don’t care if someone drop all my inventory and delete my account. If I would care about it then I would obviously not use telnet.

I run a DikuMUD that users connect to using Telnet

I really should update it to allow more secure options

> that users connect to using Telnet

Not anymore ;)

Seriously though: did you notice any spikes up or down?

If you'd run it on a non-standard port, anyone can still connect with netcat, socat, etc etc.

Ah, not really. We are on a non-standard port (9000). I just meant some folks use the telnet client to connect, and we do negotiate some telnet options. I use tintin++ these days but I think most of our players are still using decades old zMUD versions to connect!

I always preferred gmud, but zmud has all the bells and whistles. All I needed was ANSI color, aliases, triggers, and command history.

How can I get access?

ncmdu.net 9000 :)

Pretty slow these days, hack 'n slash style game

Or with telnet (the client)

To play DOOM.

  telnet doom.w-graj.net 666

On the bright side that CVE seems like pretty great news for the hardware hacking community hoping to get root on embedded devices which have open telnetd.

I just tried on a Zyxel Wifi AP I have.

It seems to use a different telnetd (busybox?), because from what I can tell it's not prone to this error.

Damn :(

The scope of this CVE and the response to it are genuinely wild.

It's crazy to think that some dude is singlehandedly responsible for ultimately ending the telnet era in such a definitive way.

One for the history books.

>some dude is singlehandedly responsible

Well, one person to put up the PR and one dude to approve it - back in 2015. It isn't the security researcher's fault.

> Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.

Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet services on the backbone relays themselves?

Most MUDs do not use Telnet.

MUDs use plaintext TCP protocols that are accessible to a wide range of clients.

The Telnet protocol is well-defined and not completely plaintext. There are in-band signaling methods and negotiations. Telnet is defined to live on 23/tcp as an IANA well-known, privileged, reserved port.

MUDs do none of this. You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.

The fact that MUDs inhabit higher 4-digit ports is an artifact from their beginnings as unprivileged, user-run servers without a standardized protocol or an assigned “well-known port” presence. If you want your MUD to be particularly inaccessible, you could certainly run on port 23 now!

As a MUD enthusiast of two decades, this is not accurate. Where are you getting this information?

Most MUDs implement RFC 854, and a number of non-standard Telnet option subnegotiation protocols have been adopted for compression (MCCP2), transmission of unrendered data (ATCP, GMCP, ZMP), and even a mechanism for enabling marking up the normal content using XML-style tags (MXP). These telopts build on the subnegotiation facility in standard Telnet, whose designers knew that the base protocol would be insufficient for many needs; there are a great number of IANA-controlled and standardized telopt codes that demonstrate this, and the MUD community has developed extensions using that same mechanism.

> You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.

I think you are confusing "telnet" the program with "telnet" the protocol. I am speaking here of the protocol, defined at base in RFC 854, for which "telnet" the program is but one particularly common implementation. You look at any of those "dedicated, programmable clients" and they will contain an implementation of RFC 854, probably also an implementation of RFC 1143 (which nails down the rules of subnegotiation in order to prevent negotiation loops), and an implementation of the RFCs for several standard telopts as well as non-standardized MUD community telopts. I can speak for the behavior of MUSHclient in especial regard here, though I am also familiar with the underlying Telnet nature of Mudlet, ZMud, and CMUD, not to mention my very own custom-made prototype client for which I very much needed to implement Telnet as described above.

Yes, perhaps we should define “MUD” and your incomplete experience of “most”.

As a MUD enthusiast for 37 years, I learned to program in C and Unix through TinyMUD, MUCK, and MUSH derived servers. From the beginning, none of these codebases implemted Telnet. There was nothing but a raw transparent TCP connection. In fact, I facilitated the introduction of a grand innovation: the "port concentrator" system which multiplexed TCP connections. Unix processes had a hard rlimit of 64 file descriptors, which crimped our style as an emerging MMORPG. The multiplexer increased this to 4096, for the biggest games of the era.

You mention MUSHclient, and I do not know about later revisions of the TinyMUSH server, but I can assure you that every MUSH I found from Larry Foard on, was not implementing Telnet. (I was privileged to help Larry "test" new features as I red-teamed his server with bizarre edge cases!)

Likewise, after I handed off TinyMUCK 2.3 to the furries, it was not doing the Telnet protocol. When we backported stuff to MUCK 1.x, it was not doing Telnet. I wrote a bonkers Perl program to read MUCK databases and sort of implement the game. No Telnet there. I've got to wonder whether the Ubermud or MOO guys had folded it in; they were close collaborators with us, back in the day.

Now as for the Diku, LP, and other “combat” type games, I’ve no idea. Perhaps they did. We never cared. I was aware that some of them had a pesky “prompt” that violated the line-mode assumptions of conventional clients and needed workarounds.

telnet(1), the program, was historically the only program that implemented the protocol. If you use Tinyfugue or Tinywar or tinymud.el, they are not, and no, I am not confused, because I was giving an example of why the Telnet-implementation, the program, the client, was so inadequate for playing on MUD servers.

It wouldn’t have been difficult to retrofit the Telnet RFC 854 into any MUD server, but none of us wizards had any use for it, seeing that our clients were mature and capable of much more processing without it.

If modern MUD servers have mostly implemented Telnet, then that is cool, but what surprises me is that it is mandatory, and your clients don’t seem to interoperate without it? That is a strange reversal!

The modern MUSH forks do generally support telnet, but yes -- as a 29 year old who's been pathologically obsessed with "MUD archeology" off and on, I'll confirm -- historically, most MUDs did not do any sort of Telnet negotiation.

Further, most older clients did not anticipate any kind of Telnet negotiation from the server, and will print garbage to the screen if connecting to modern MUSHes that do. (I've tested tinywar, vt, and that one VMS client...)

MUCKs never, to my knowledge, implemented telnet, though. They barely support ANSI escapes, nevermind Telnet. :-)

> [...] no, I am not confused, because I was giving an example of why the Telnet-implementation, the program, the client, was so inadequate for playing on MUD servers.

Then this is at the heart of our disconnect, because the post of mine that you originally replied to --- as well as, unless I drastically misread, the original article under discussion --- was concerned with traffic on port 23, the Telnet protocol port, and not with any particular implementation communicating on that port. The concern of my original comment was that this might affect MUDs that operate on port 23. Perhaps you can understand my confusion when you reply stating categorically that most MUDs do not use "Telnet" (meaning the program), when that wasn't really what was at concern (and therefore implied that my question had no basis).

It is a true fact that many MUDs operate on port 23. Many do not, but you can skim a MUD aggregator like MudConnect [0] to see that it is quite common. Aardwolf, Discworld MUD, and the IRE games --- which consistently topped TopMudSites (when that aggregator was still running, anyway) all operate on 23, potentially in addition to an unreserved port.

> what surprises me is that it is mandatory, and your clients don’t seem to interoperate without it? That is a strange reversal!

All telopts are disabled by default, per Telnet RFC; the only things you must absolutely parse under the RFC are the standard complement of NVT commands (such as IAC GA "Go Ahead"), even if they are otherwise implemented as no-ops.

Any input stream with the high bit clear is treated as pure data -- with the incidental exception of bare `\r`, which must always be followed either by `\n` or by `\0`; but Postel's Law has turned that into more of a guideline. So as long as the standard NVT encoding is assumed (which is just 7-bit ASCII) and the NVT core escape sequences are avoided, a modern Telnet-based MUD client can interoperate with a plaintext MUD server without issue. (As you know, this is also why people get away with using `telnet` (the program) to access HTTP and SMTP services instead of using something like netcat.)

Some MUD clients will eagerly send IAC DO / IAC WILL subnegotiations, but general practice is to let the server offer first -- probably precisely to ensure compatibility with MUDs that don't implement Telnet subnegotiations.

> Now as for the Diku, LP, and other “combat” type games, I’ve no idea

Diku-family MUDs are certainly the ones I have the most experience with. I understand LP MUDs also generally have Telnet support; or at least, I recall seeing a patch for them that MUD owners often sought to apply to their games.

[0]: https://www.mudconnect.com/cgi-bin/search.cgi?mode=tmc_bigli...

in particular it is very rare I find a running diku or lp that does not at least use the telnet ECHO option to attempt to control password display.

> MUDs do none of this.

MOOs do.

It wasn’t clear from the article but I assumed they were filtering for the attack specifically.

Since Telnet is totally plain text that would absolutely be easy to do right?

Wouldn't that imply that >80% of all monitored telnet sessions were exploit attempts for the specific CVE in question? Even with the scale of modern botnets, that seems unrealistic for a single vuln that was undisclosed at the time.

I have a hard time thinking it’s popular enough these days that attacks, attempts at attacks, or just command and control couldn’t be the main use.

Not at interconnect speeds

It seems like they are doing a port based block similar to how residential lines often have their SMTP ports shut off.

That said in this day and age, servers on the public network really ought to use SSH.

The CVE referenced is caused by this commit:

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...

One of the changes is:

    -  getterminaltype (char *user_name, size_t len)
    +  getterminaltype (char *uname, size_t len)

From ChangeLog:

    * telnetd/utility.c (getterminaltype): Change the
      name `user_name' to `uname', as the former shadows a precious
     and global variable name.

Congratulations! Now you've got yourself a precious and global(ly exploitable) vulnerability...

Wouldn't attention to getenv() calls yield more benefit? Such calls are where input typically isn't parsed--because parsing is "hard"--becoming targets for exploit.

The present fix is to sanitize user input. Does it cover all cases?

It should be possible to get a better idea where the filtering happens with a tool like tcptraceroute (possibly patched to use other segments beyond the default TCP SYN).

I haven't found evidence of extremely widespread filtering. Why would there be? The installation count is not that high. The potential side effects from uncoordinated port filtering could be quite severe. This isn't netkit's telnetd or Busybox. (I'm aware of Debian switching defaults, but that was fairly recently.)

When I was an intern for some reason they issued me a voip phone for my desk. One day I got bored and figured out I could telnet into it. Nothing interesting but it was still a fun moment for me!

A very very long time ago as an intern I was working on a perl cgi script and I would often test it with telnet. I was used to messing around with hayes commands so manually typing in HTTP commands seemed like a natural extension of that.

If you miss that and long for the olden days, you can still do it today with OpenSSL’s sclient:

  openssl s_client -connect www.yahoo.com:443

I did this too, lol

So eleven years ago someone put a backdoor in the Telnet daemon.

Who?

Where's the commit?

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...

That link goes to a page full of random garbage. No commits there to be seen.

Apparently the owners of that website don't like my choice of user agent, and have decided to punish me accordingly.

Same here. It says please wait while verifying.

I just checked, and it's confirmed: I am definitely using a web browser. It seems my browser and this site have a different definition of web standards, however.

So exhausting to be surrounded by people with a paranoid, irrational fear of robots, who don't give a shit who they harm in their zeal to lash out and strike the evil bots.

That's crazy. This is core business critical software but they just YOLO critical changes without any automated tests? this PR would be insta-rejected in the small SAAS shop I work at.

Culture has changed a lot since the 20th century and older projects can have antiquated norms around things like testing. I was just listening to a recent podcast talking about how worrisome it is that OpenSSL has a casual culture about testing[1] and was reminded about how normal that used to be. I think in the case of telnetd you also have the problem that it’s been deprecated for multiple decades so I’d bet that they struggle even more than average to find maintainer time.

1. https://securitycryptographywhatever.com/2026/02/01/python-c...

Even with automated tests you'd need to think of this exploit right? Perhaps fuzzing would have got it. The mailing lists says they proved it successful on

- OpenIndiana

- FreeBSD

- Debian GNU/Linux

So not complete YOLO.

See https://lists.gnu.org/archive/html/bug-inetutils/2015-03/msg...

FWIW, a well known LLM agent, when I asked for a review of the patch, did suggest it was dodgy but didn't pick up the severity of how dodgy it was.

> a well known LLM agent

Which one?

Not GP, but my local Ministral 3 14B and GPT-OSS 20B didn't catch anything unless I gave some hints.

He says 'well known' so I assume Claude or GPT, I just don't get why he's being coy.

I thought by not naming it wouldn't shift the focus to the particular model, but it did the opposite. It was gpt-5.3-codex in medium mode.

If you think you can do better you're welcome to do better. I say this without a hint of sarcasm. This is how open source works. It's a do–ocracy, not a democracy. Whoever makes a telnet server gets to decide how the telnet server works and how much testing it gets before release.

Maybe the lesson here is to stop letting the GNU folks do things, if this is what they do. This is only one example of craziness coming out of the GNU camp.

Or, flip the responsibility to what it has always been understood to be, when using open source software from random volunteers (some being bad actors) on the internet for anything remotely critical: audit the source.

GNU doesn’t provide labor, only organizational tools like mailing lists and whatnot. The projects that GNU supports are still run by individual volunteers. If you want it done better then please volunteer so that you can be the one doing it better.

I am the one doing it better. GNU software is slowly being deprecated on my system, starting with glibc.

So you’re just changing which volunteers you depend on? That’s really productive of you. Thank you for your service.

[flagged]

You can enslave yourself to Microslop if you prefer.

Any business that has a telnet daemon able to be reached by an unauthenticated user is negligent. Just the fact that everything is in the clear is reason enough to never use it outside of protected networks.

unless it doesn’t matter if it’s evesdropped

Traffic could be tampered as well.

Sometimes that doesn't matter either. That is the valid use case of a plain-text protocol like telnet: doesn't matter.

Most 90’s era software had zero tests. Nobody gave it a second thought.

Early '90s maybe. By the late '90s people knew tests were a good idea, and many even applied that in practice.

There's a famous XKCD about this: https://xkcd.com/2347/

In this case the hero's name is apparently Simon Josefsson (maintainer).

I feel like we should just start saying 2347. Everyone knows what you mean.

https://xkcd.com/2347/

Ah, someone beat me to it!

It can't be critical business software if the business to which it is critical isn't paying anything for it.

/s

Telnet's cleartext and always has been. A backdoor seems like overkill.

You still have to know the password or snoop on someone typing the password. But with this vuln, you don't. You can just get root instantly.

> backdoor

Do you mean that it's intentional? Why do you think so?

It wasn't a backdoor, just a very serious security bug. Congrats on jumping straight to conspiracy and paranoia, though.

It's only a conspiracy and paranoia if it's wrong. 11 years ago was 2015.

It is wrong. The author is known, was acting in good faith, and simply fucked up really badly.

I don't know what 11 years ago has to do with anything, besides the awful lifespan of such a severe bug.

> GNU organization

> giant security flaw

Checks out.

I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along.

What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:

  $ login '-f root'
  login: illegal option --  

You passed '-f root' to login (a single long string). telnetd is likely passing '-f' 'root' to login (two arguments instead of one, whether this is because it creates two, or it uses the shell (which then reparses) I don't know).

But '-f' is a valid option to login (man login):

login [-p] [-h host] [-H] [-f username|username]

...

-f Used to skip a login authentication. This option is usually used by the getty(8) autologin feature.

I was reading https://www.offsec.com/blog/cve-2026-24061/, which implies that precisely that single long string passes through getenv("USER") in the attack. The mystery is how that single long string in telnetd becomes two separate arguments for login. execv or posix_spawn certainly won't do that. So either there's a version of /usr/bin/login that parses arguments in some very sus way, or there's a shell involved somehow.

It's nice to not see C being blamed for once! ... Just good old lack of reasoning (which is most C's codebase downfall, agreeably).

Argument injection can happen in any programming language where you can concatenate strings and call something with the result.

It's also not DNS!

Or Windows, for a change!

Or Notepad, for a change!

Kind of "funny" affected service is BGP RouteViews CLI access, still running over telnet: https://archive.routeviews.org/ (scroll to bottom of the page)

Isn't this one of the remaining, "legit" uses of the Telnet protocol on TCP/23 port over the public Internet?

Stranger article. I wasn't able to get the main point of this article. Strangely written, but hey - I'm nob native by any means.

ps.

telnet SDF.org

just works...

it was just ai written thats why.. unexpectedly so from greynoise.

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.

The rest of it seems to be substantially edited by an LLM too, or at least it's composed much like LLM outputs often are these days: “not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function.”

"Not X, not Y, not Z" is a common LLM tic, and there's a few more like it in there.

I mean, that's fair. I guess I just wanted to put my old man hat on. The song is a tribute to an era of lost innocence. Which I think is quite apropos to the current situation surrounding telnet. Vestiges of the days of the early internet continue to disappear, almost like an endangered species. Old/obsolete protocols, like telnet, are pined for by old guys like me.

Oh, I have fond memories, I learned to touch-type playing MUDs.

I was at a bar a few months back, drinking some brewskis with my broskis, and there was a guy with a guitar playing some songs. He started singing (bye bye miss) American Pie. Somewhere around the 4th verse he got stuck in a loop and sang that verse 3 or 4 times before he gave up.

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.

Thats what the mystery exceptions for the Open Group macOS UNIX certification was for!

telnet has never been in POSIX though.

It's a joke and a poke that macOS isn't certified UNIX as shipped.

https://www.opengroup.org//openbrand/register/

To actually pass the certification test suite on a real system, Apple sometimes needs to apply special configurations (e.g., disabling System Integrity Protection (SIP), using case-sensitive filesystem, enabling certain legacy services, etc.).

telnet(1) is not required by POSIX (nor is nc or ssh required!)

Ironically, telnet(1) did not begin as a "Unix" utility but an ARPANET protocol suite program. It was available cross-platform. It is unclear whether all editions of Unix included a client, but BSD for sure was the point where telnet and TCP/IP became essential integrations for the systems.

There's always nc hostname 23 unless you need authentication

There's no UNIX requirement for telnet.

Ubuntu does not include it by default (starting 16.04?). Most most distros don't.

Two wrongs don't make a right.

Apple still includes uucp for some unknown reason.

The saving disk space argument makes no sense because telnet was one of the smaller binaries in /usr/bin.

Telnet continues to be widely used for select use cases and being told we're naughty by not including it feels punitive and just adds extra steps. What are you supposed to do, trash a $1m piece of industrial equipment because Apple wants to remind you Telnet is insecure?

New devices are still being released with Telnet where SSH is impractical or unnecessary.

There are many things I want to say in reply to this. So I’ll bullet point them:

* yes, do not buy equipment that has acquired so much tech debt that it still requires telnet.

* there are a million telnet clients out in the world. And ones far better than the default OS one. Apple not shipping one standard is not the end of the world or really anything more than a mild inconvenience for the small handful of people who need actual “Telnet” as opposed to Netcat or socat, both of which are far better than base Telnet.

> yes, do not buy equipment that has acquired so much tech debt that it still requires telnet.

No, you already own this capital equipment. It's the laptops running macOS that are ephemeral and disposable.

I don't care for excuses or workarounds; why did they do it?

It was an explicit decision whilst leaving a lot more—arguably more useless—garbage in.

Every OS that removed telnet did so for a symbolic reason, not because it was helpful technically.

It seems rather typical for Apple. The removal of the headphone jack obsoleted thousands of consumer devices.

You can have it, it’s not on the base install.

99% of Mac users never use it, directly or indirectly. Asking that they have it anyway is a self centric view.

Ubuntu and derivates removing telnet from the default install, along with other basic tools like traceroute etc, was one of the driving factors toward me creating my own distro. I'm sick of basic stuff being omitted because somebody just decided it's not needed anymore.

How on god’s green earth is `sudo apt install telnet` sufficiently challenging to be a driving factor to creating your own distro??

Because I go long periods of time without internet access, and I don't want to have to "sudo apt install" a fucking thing, ever. Especially not a tiny utility that is all of 172k in size, that I might need for something. Understand?

I want EVERYTHING that I might use installed AT ALL TIMES, FROM DAY ONE, so that I can IMMEDIATELY USE IT when required.

This is only one of many reasons why I abandoned the giant dumpster fire that is mainstream Linux. I do not agree with their idiotic philosophy, on practically every level.

You've now discovered that there are sections of God's Green Earth that you never knew existed! One of many benefits of stepping outside the Matrix for a moment.

I would never ever install your distro for this reason alone.

Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt.

Removing the telnet client was, in part, a recognition that its complementary server was deprecated and unsafe. If everyone was transitioned to ssh and nc, [and custom MUD clients], why keep telnet around?

Any software like this represents tech debt and a support burden for the upstreams and distros which carry them. You have unnecessarily assumed a burden in this way.

Furthermore, ask the maintainers of OpenBSD or any hardened OS about attack surfaces. The more software that you cram into the default distribution, the more bundled features an OS or system has, you are multiplying your potential vulnerabilities, your zero-days, and your future CVE/patch updates.

Especially in the face of growing supply-chain attacks and LLM-automated vulnerability disclosure. Your focus should be on limiting attack surface in every regard.

It is good practice for everyone to uninstall unnecessary apps and software. Whether you use Android, iOS, Mac, Linux, BeOS or Plan9 or Inferno. Do not install and maintain software that you do not use or need. It will come back to bite you.

> I would never ever install your distro for this reason alone.

And you are? Completely mystified as to why you'd think I would care. I built this distro for me and my people, not you. That's the whole point. We're getting off this ride.

> Someone has already pointed out that old/deprecated/obsolete software like a telnet client represent tech debt.

Not a subscriber to this religion. There is nothing about new software that inherently makes it safe, and nothing about old software that inherently makes it vulnerable.

New flaws are introduced all the time, and old bugs do get found and fixed.

I can patch old code. I can't guarantee that new code doesn't contain bugs.

The ONLY way to ensure code is flawless is through validation--mathematical proof. When you have devised a proof framework that I can use across my distro, get back to me. At this time you're nowhere near that level, and are therefore unqualified to lecture anyone about security.

> Removing the telnet client was, in part, a recognition that its complementary server was deprecated and unsafe.

Unsafe? On my personal LAN? I think not.

You don't get to just 'deprecate' things that I might need, or want to use for perfectly valid reasons.

That's the entire point of my distro: computing the way I WANT IT, not the way Ubuntu wants it.

> If everyone was transitioned to ssh and nc, [and custom MUD clients], why keep telnet around?

Because it's 172 kilobytes. Contrast with the giant bloated carcass of everything else they shove in there that's oh-so-needed by the herd.

> Any software like this represents tech debt and a support burden for the upstreams and distros which carry them. You have unnecessarily assumed a burden in this way.

I'm a distro maintainer. Hello? Telnet represents ZERO maintenance burden for me. There are no operators standing by on hotlines to "support" any of this. It's a 172 kilobyte utility.

> Furthermore, ask the maintainers of OpenBSD or any hardened OS about attack surfaces. The more software that you cram into the default distribution, the more bundled features an OS or system has, you are multiplying your potential vulnerabilities, your zero-days, and your future CVE/patch updates.

Nobody can magically teleport themselves inside my computer and compromise my telnet client. Nobody is injecting packets into my LAN.

> Especially in the face of growing supply-chain attacks and LLM-automated vulnerability disclosure. Your focus should be on limiting attack surface in every regard.

You're concerned about supply chain attacks, so your mitigation is...doubling down on getting the Latest Updates to everything? Because new code is inherently good.

Telnet has to go--way too risky to keep that around--but KDE/Gnome/systemd/dbus/etc stays?

'traceroute' is useless and dangerous, but let's keep the giant QT framework with its vendored copy of Chromium? (That's QT5 and QT6, each with a vendored Chromium, mind you.)

Chromium, by the way, itself represents tens of gigabytes of code/data now inside its repository, with 'third party' directories vendored three or even four levels deep. But a 72k traceroute utility is likely to be packed with security flaws and should be avoided.

> It is good practice for everyone to uninstall unnecessary apps and software. Whether you use Android, iOS, Mac, Linux, BeOS or Plan9 or Inferno. Do not install and maintain software that you do not use or need. It will come back to bite you.

Completely wrong and misleading theory of security you are proposing here.

I devised this new distro exactly because I was tired of my computing experience being shaped and controlled by clueless kids with intellectually bankrupt arguments and/or wolves in sheeps' clothing.

Well this is weird.

You talk about me, my, mine, my network, my computer. But you're promoting a "distro". That means you're distributing software. It's not yours anymore.

Attackers on a network will use techniques to "pivot". Once a "foothold" is established then they scan for other places to attack. They will indeed get inside "your" computer, or router, and then compromise your telnetd.

It comes back to the liberty of swinging your arms vs. the proximity to my nose. If your distro is connected to a network, then you're responsible and accountable for security issues that result. There are thousands of distro kiddies sending out their favorite flavor of Linux, but how many audited it like Theo de Raadt?

You don't seem to understand the CVE under discussion. It doesn't even affect telnet(1). Practically nobody runs telnetd(8) anymore since the introduction of encryption, ssh, and the like. MUD players use MUD clients. Network admins use nc(1). The reason "telnet" was deprecated is: it's just not really useful anymore without its complementary service. telnet(1) isn't inherently dangerous, it's just superfluous, and distros pretty much evaluated that it wasn't worth hanging on to.

As for "traceroute", I'm not sure it's "useless or dangerous", but it can be misleading and definitely superfluous. It is widely misinterpreted by novices trying to prove something about their WAN connectivity. It misrepresents network topology and doesn't work real good with modern equipment or protocols. It was a judicious decision to bundle it with network debugging tools, because not everyone needs to debug networks. Especially the ones who believe that they can.

I would say that any network debugging tool available is also useful to your attackers with a foothold. A "living off the land" attack will leverage your telnet client, will run traceroutes on your network, and they will use all the software cruft that you didn't uninstall! I am pretty sure there are distros that simply don't come with development environments, C compilers, or various interpreters anymore, and it is for this reason: they are not inherently insecure or vulnerable, but "living off the land" will weaponize them every time.

However, I must concede that your temperament and tone is well-suited to being a distro administrator. You remind me of Linus Torvalds vs. Andrew Tanenbaum, or Theo de Raadt vs. FreeBSD. Perhaps Scott Adams vs. the world. Carry on, good sir.

> You talk about me, my, mine, my network, my computer. But you're promoting a "distro". That means you're distributing software. It's not yours anymore.

It's OURS. It was never YOURS. Get it?

> Attackers on a network will use techniques to "pivot". Once a "foothold" is established then they scan for other places to attack. They will indeed get inside "your" computer, or router, and then compromise your telnetd.

Oh no! Someone is going to hack into my LAN! I guess I'd better keep the shotgun loaded.

Are you aware that your entire computer is backdoored, starting at the CPU level on up? It's like you don't realize this. Your 'security' = gaping asshole, same as everyone else these days. And you're worried about telnet?

> It comes back to the liberty of swinging your arms vs. the proximity to my nose. If your distro is connected to a network, then you're responsible and accountable for security issues that result.

Fascinating new legal/morality theory you've concocted. No, I am in fact not responsible for some noob running a telnetd on the open internet then getting hacked. Craziness.

Wait a second. Are you also the type of person who is susceptible to the bullshit belief that, because I never got the, quote-unquote ''covid vaccine'' (nor the flu vaccine, nor any other), that I'm somehow a threat to you? Are you one of those people too?

> You don't seem to understand the CVE under discussion.

You don't seem to understand much of anything.

> The reason "telnet" was deprecated is

I've just explained to you that it hasn't been 'deprecated' at all ON MY SYSTEM. What you choose to do is irrelevant.

> As for "traceroute", I'm not sure it's "useless or dangerous", but it can be misleading and definitely superfluous. It is widely misinterpreted by novices trying to prove something about their WAN connectivity.

And here we come to the epicenter of your problematic thinking:

I am not a novice. I'm a power user. Get it? I've been doing this shit for decades. I'm sick to death of my entire life being ruled and dictated by the 'needs' of morons. You can keep your Play-Skool OS and padded walls, thanks.

Really, your entire philosophy is so full of logical contradictions. You're scared to death of telnet/traceroute, but you're cool with having this giant package ecosystem where you are constantly streaming Other People's Binaries to your system, and you think that is safe, and would never be hacked or used against you. Clueless.

Go argue with a brick wall; you'll get further. I know what I'm doing.

[dead]

The easiest way to make your own “distro” is apt-get install stuffiwant…

Netcat works as a telnet client. GAWK can do that too with a dumb loop. So can con(1) under 9front.

Using netcat results in showing Unicode replacement symbols, instead of answering to telnet options. I doubt it implements telnet at all, because this is just not its job.

Port 23 has decreased significantly over the past decade:

https://i.imgur.com/tZoTWu6.png

Still seeing a sizable number of open ports but it's on the decline.

Am I the only one who feels like it isn't the responsibility of backbone ISPs to filter traffic like this? In the case of a DDoS situation I could get behind it, but in this case I feel as though it's not Cogent's problem if I want to use telnet from a device on Charter's network to a Vultr VPS, even if it may be ill-advised.

(Of course, the article only speculates that this traffic filtering is what's going on; there isn't any hard proof, but it feels plausible to me.)

Telnet will live on, in areas it probably shouldn't like industrial controls systems, switch management, regulated industries, printing, etc.

Interesting... I hadn't been watching, but I average around 2000 unique IPs for telnet... there was a brief 7500 IP spike in the middle of January, but it was short lived. There was a smaller blip just at the end of January, but going into February it's actually down around 1000.

For about 15 years beginning in 2003 I had some VPSs with CrystalTech/NewTek. I noticed right away that they had blocked all port 23 traffic in/out of their edge.

I asked them about it and they said it was a security measure. Apparently they used telnet for managing their routers.

It turned out that they did not have very good security anyway.

https://krebsonsecurity.com/2018/02/domain-theft-strands-tho...

I switched to A2 hosting shortly after the above incident, but I dumped them when they did not keep up to date on their Ubuntu LTS OS options.

I've been running on AWS for the past eight years. It costs more, but it's been extraordinarily reliable.

A2 and AWS do not restrict port 23.

I still used telnet today (had to). Unsure of the patching here. But its definitely locked down to a subset of internal use only.

Embedded? Ancient? What sort of systems are you telnetting into?

Not the parent poster, but I also still use telnet. For me it's "Ancient", I have a few retired SPARC and PA-RISC boxes that run their period appropriate OSes as a hobby. Telnet/rlogin is the more reliable method to get into them remotely (just over the LAN).

They're on a LAN behind a NAT Router/Firewall, and I don't always keep them powered up (I'm not that insane) so I really don't have a concern for them.

Some of the more modern/high-performance examples I have run NetBSD with modern sshd and modern ciphers, but you can tell it's a bit of a workout for them.

77k hosts with port 23 open https://www.shodan.io/search?query=telnet

FYI: it might be better to search by port:23

https://www.shodan.io/search?query=port%3A23

Or to filter by product:telnetd

https://www.shodan.io/search?query=product%3Atelnetd

A query of "telnet" searches Shodan for banners where the "data" property contains the string "telnet":

https://book.shodan.io/getting-started/query-syntax/

It's more like telnetd died rather than telnet died.

btw if you want a quick telnet client, and an old python happens to be installed, you can use `python -m telnetlib IP`

Since Tier 1 transit providers have now blocked telnet (port 23), this means the death of watching ASCII Star Wars with `telnet towel.blinkenlights.nl`

However, if you still long for nostalgia, I was able to access it over IPv6 using a VPN based in the Netherlands:

    telnet 2001:7b8:666:ffff::1:42

The design of telnet and ssh where you have a daemon running as root is bad security that as shown here is a liability, a ticking time bomb ready to give attackers root.

Oldschool telnetd didn’t actually run as root; rather, it just set up a PTY for the incoming socket to talk to, and then fork-exec’ed a /bin/login subprocess to live inside that pty. /bin/login is setuid-root, so it’s “where the security lived.”

I think we all collectively decided that that was a bad idea at some point — probably because /bin/login was never designed under the assumption that it would have to deal with arbitrary binary network traffic being thrown at it (it really only expects keyboard input.) So we switched to doing auth directly in our network daemons, since at least then “people who are aware the code is network-facing” would be maintaining it.

What do you think proper architecture would be, given that ssh needs a capability to let root logins?

I suppose it could be via a proper PAM module, which is widely supported.

Too bad the first PAM RFC was published about the same time the first be version of ssh was released.

> ssh needs a capability to let root logins

One can disable root login via SSH in /etc/ssh/sshd_config. sshd also drops root priviledges once it's running IIRC.

I use use sudo or doas as a regular user once logged in.

Does ssh need to allow root logins?

Sshing as a regular user and then sudo to root works 95% of the time…

How does SSH become an arbitrary user without effective root?

SSH should not become a different user; it should call something like `/bin/login` which uses PAM for authentication and is capable of starting user sessions.

I think a proper architecture would not even have a root account. The server would just expose an authenticated endpoint that allows for configuration and updates to be pushed for it.

You are thinking 20 years ahead. In 1995 most servers were still pets, not cattle.

OpenSSH has been moving quite quickly in the direction of multiple, privilege separated processes, each also heavily sandboxed with pledge and unveil

Literally how else is a remote login daemon supposed to work though?

1. Start with root to bind the port below 1024.

2. give up root because you don't need it any further.

3. Only accept non-root logins

4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

That still needs a way to change users, and OpenSSH already has privilege separation. That hardens the process somewhat to reduce the amount of code running in the process which can change the uid for a session but fundamentally something needs permission to call setuid() or the equivalent.

Yes, but changing users is a function of the shell (or maybe more specifically /usr/bin/login), not the SSH daemon.

Yea, but then we’ve recreated this CVE which is caused by calling login(1) unsafely. The point was that the person I was replying to misunderstood the problem and largely seemed to be conflating telnetd with OpenSSH.

Congratulations, you've created a server that lets people have shells running as the user running telnetd.

You presumably want them to run as any (non root) user. The capability you need for that, to impersonate arbitrary (non-root) users on the system, is pretty damn close to being root.

Well obviously each user just needs to run their own telnet daemon, on their own port of course.

You still need to have privileges to become the userid of the user logging in. Openssh does do privsep, but you still need a privileged daemon.

I'm not sure that you need root because of the port - I think login itself needs to run as root, otherwise it cant login to anything other than the account its running under.

The remote daemon has its own account and is given a privilege that allows it to connect a network socket to a pseudo terminal.

Those are already unprivileged operations, but how does it start the initial process in that terminal with the correct privileges for a different user?

The kernel could authenticate the user before starting it.

How does it do that?

There are many ways from passkeys to SAML. Though for complex methods we may want a dedicated services outside the kernel.

How does that service get launched with the privilege to switch to any user?

The kernel can start a process with any user it wants. The user doesn't have to switch during the process's life.

Any breach of the daemon will still give access to a system that can approve/deny user logins. Breaching the daemon therefore allows permission escalation, because you can simply jump to an account. Chain with any local vuln of your choice to completely own the box.

It doesn't matter what user it is running as.

If this was so easy to deal with, someone would have done it. Instead, we get endless HN comments about people that act like they can do better but never submit a PR.

Breaching the daemon only allows for the attacker to get access to the login. User accounts should still be secured requiring authentication.

>If this was so easy to deal with, someone would have done it.

Sadly this is not the case. There is a lot of inertia towards solutions like ssh or sudo. It may be easy to delete them, but actually getting such a changed accepted is no trivial task.

> Breaching the daemon only allows for the attacker to get access to the login

Yes, but potentially any login. See the problem? If you compromise the gatekeeper, you are now the keymaster. Or whatever :)

I'll admit it is still problematic. But at least there is only 1 gatekeeper instead of 2.

How is that better?

You can focus all of your energy into strengthening and testing a single point of the system instead of having to do it for many.

You're grasping for straws a bit here. This is already done for ssh as the defacto remote access mechanism for a very long time.

More likely a specific botnet had it's c2 or telnet scanning report endpoint go down / get nulled on Jan 14th.

This is about Telnetd. Not telnet itself.

  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.

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.)

I'm not sure I understand how this argument refutes the claim that this isn't about telnetd. There'd be no reason to respond to the vulnerability in the way they did if the vulnerability in telnetd hadn't existed and been exploited -- and the proof is that nobody ever did until now.

...except that port 23 seems to now be filtered across the internet at large, leading to a huge drop-off in telnet traffic over the course of days if not hours. I think it's safe to say that even if you patch telnetd, being able to use telnet over the internet is not possible in many places (including Canada, according to the data).

I wonder if simply moving to a nearby port would work. I assume only port TCP/23 is filtered instead of filtering the telnet protocol itself.

Between you and me telnet is not dead. Sometimes I use it to probe a port to verify it is working.

You might wanna use netcat for that instead [1]. Or, for example, socat [2]. Netcat has been around for a long, long time now.

[1] nc (1) - arbitrary TCP and UDP connections and listens

[2] socat (1) - Multipurpose relay (SOcket CAT)

That's not really telnet. Yeah, it's using the same client, but the server and underlying protocol are what's relevant here.

The modern replacement for telnet used in the "probe a port" fashion is nc/netcat.

I used to telnet into my POP3 account and check email by protocol. Shucks.

Your dial up ever die when you where checking your email? My ISP didn't allow for leave copy on server, I remember times I lost emails to this.

Why would somebody read something that somebody couldn't be bothered to write? This article is AI slop.

What stood out as AI written? It felt like a well-written article by an SME to me.

Not the original commenter, but I noticed it too. I guess it's hard since AI is trained on human content, so presumably humans write like this too, but a few that stood out to me:

> Five entire countries vanished from GreyNoise telnet data: Zimbabwe, Ukraine, Canada, Poland, and Egypt. Not reduced — zero.

> An attacker sends -f root as the username value, and login(1) obediently skips authentication, handing over a root shell. No credentials required. No user interaction.

> The GreyNoise Global Observation Grid recorded a sudden, sustained collapse in global telnet traffic — not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function. One hour, ~74,000 sessions. The next, ~22,000.

> That kind of step function — propagating within a single hour window — reads as a configuration change on routing infrastructure, not behavioral drift in scanning populations.

(and I'm not just pointing these out because of the em dashes)

GPTZero (which is just another AI model that can have similar flaws and is definitely not infallible, but is at least another data point) rates my excerpts as 78% chance AI written, 22% chance of AI-human mix.

To me at least, the article still seems to be majority human-written, though.

Also, one of the authors is "Orbie", which looks like an AI name, and if you go and read through some of the recent posts, all of the posts with that author feel very LLM-y and bland, and the posts without that author are much more normal.

GGP has a good eye.

Personally, I found the spoof song in the middle of very dry writing to be jarring. But I didn't think it sounded AI written.

[dead]

Am I the only one who finds this suspicious ? About Telnetd “…The vulnerable code was introduced in a 2015 commit and sat undiscovered for nearly 11 years.”

Okay, it is really weird. This was not an exploit difficult to pull off, or discover. It is such an elementary error that any script kiddie could have leveraged it anywhere, once it was understood.

Is there proof or evidence that it was never exploited in all of 10 years and remained as a latent zero-day?

The only saving grace I would propose, is that since telnetd has been aggressively deprecated once ssh became popular, and encryption became ubiquitous, and remote exploits became commonplace, and Starbucks WiFi was routinely surveilled, that telnetd simply wasn't running anywhere, anymore.

We have commenters saying that embedded systems and IoT used telnet servers. But were they running an actual GNU telnetd or just a management interface that answered on port 23/tcp? Commenters are citing statistics of "open port 23", but that means nothing in terms of this CVE, if it ain't GNU telnetd. Cisco has literally always used port 23 for management. Other routers and network devices use port 23 without telnetd.

How popular was GNU telnetd to be running on a system and exposed to the Internet? This article pertains to all the port-scanners running everywhere, so surely someone with a Shodan account can make a survey and tell us: who was still exposing GNU telnetd in 2026?

There will be some honeypots in this data but this is a start:

https://www.shodan.io/search/report?query=product%3Atelnetd+...

Time to switch to SUPDUP!

Ah. Telnet. My oscilloscope still talks telnet, and this is the reason why that type of equipment is on an isolated net.

Your cookie banner is very inconvenient and made me leave your website and not read the article

> required. No user interaction. The vulnerable code was introduced in a 2015 commit and sat undiscovered for nearly 11 years.

I think about this quote a lot: given enough eyeballs, all bugs are shallow

telnet isn't just for ... telnet.

  $ telnet smtp.example.co.uk 25
  HELO me
  MAIL FROM: gerdesj@example2.co.uk
  RCPT TO: gerdesj@example.co.uk
  DATA

The difference between "telnet" the program and "telnet" the protocol is especially important in this discussion, I think.

A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two protocols that if you're just using it to transfer plaintext it will probably work out fine, but they are distinct protocols.

I used telnet(1) as a generic TCP text client for many years before switching to GNU/BSD netcat. Nowadays, netcat is more prominent then telnet, and telnet had its corner cases with control characters.

Never heard about https://jetmore.org/john/code/swaks/, thanks for the tip.

You want nc (usually with -v) or socat. telnet is muscle memory for a lot of people (myself included sometimes) but it's a strictly inferior choice these days for poking arbitrary plaintext services.

As long as it works, it doesn’t really matter for a quick test.

I find myself using curl telnet://server:port too often these days because telnet and nc don’t get installed.

I discovered swaks recently, god I love that tool

Who actually uses the tectia ssh client instead of openssh?

telnet + shijack = good times

port 22 2FA

The pattern points toward one or more North American Tier 1 transit providers implementing port 23 filtering

Someone attempted to compromise my home router last week using CHARGEN. Can you imagine!

Attempted to compromise, or just port scanned?

Good call-out! Yes, while the router labels it as "DOS Attack" it is probably a simple port-scan!

However, anyone who knows the nature of CHARGEN would recognize that a singular successful connection could immediately blossom into a somewhat lackluster DDOS, as the chargen service risked consuming CPU and network resources unnecessarily.

chargen has been also aggressively deprecated, far more than telnetd, since it was a non-essential service. I'd like to know how many servers are voluntarily running chargen on the public Internet today.

A port-scan for chargen is more likely a comprehensive port-scan that is just attempting to identify and fingerprint anything that may have been established on that port. It would be less surprising to find, like, ssh or a web server occupying that space today.

[dead]

[dead]

I think it would be better suited to use the terms we use for natural languages. A natural language is dead when the last person who learned it as first language dies and are extinct when there is noone that would speak it at all.

In these terms, telnet has been dead for a long while, but it's extinct now.

Even that's argued within linguistics. There are languages which survive for generations as secondary languages (especially trade languages as Swahili or Chinook Jargon appear to have been originally). Also some like Latin, Hebrew and Sanskrit which survive for centuries but not as native languages.

Can you cite sources where this is argued?

The wikipedia seems to make a clear definition:

https://en.wikipedia.org/wiki/Language_death

That said, the above article does use extinction and death somewhat interchangably later on, but I suppose it's almost the same for small languages that nobody learns who is not a native speaker.

There are plenty of languages which exist without much in the way of L1 speakers. Esperanto, for example, although it does have a handful of native speakers. Many people speak English as a non-native language, particularly in places like India or Nigeria. Swahili was originally a trade language few folk spoke and even today, many of its speakers are L2.

I can speak and read some Manx. I personally don't believe it died in the 1970s. Not only do we have continuity from that time, there are people around today who learnt theirs off native speakers (in one case they were his close relatives.) It helps that we have many recordings, writings etc and it is also closely related to two languages which are in slightly better shape.

Latin and Hebrew were in use within the Middle Ages to a substantial level and used to communicate between people as a common language sometimes. Hebrew is now revived, but is Latin? A few people have spoken it as their first language over the last century or two.

[dead]

[flagged]

The most interesting thing here isn't the CVE - it's the invisible coordination. A backbone provider acted on advance knowledge of a critical flaw, implemented filtering at scale, and the rest of us didn't notice until GreyNoise's data showed the drop. The vulnerability got patched at the network layer before it ever reached the application layer. This is what mature security ecosystems look like - the boring, quiet fixes that happen before the press release.

Stop spamming AI slop

?

You comment reads very AI generated. From the, it's not X it's y, to the overdramatization of completely normal events (i.e. key infrastructure providers are notified of CVEs before they are disclosed so impact is minimized)

because it reads like claude output?

and also the pattern:

> The most interesting thing here isn't the CVE… This is what mature security…

> The most interesting finding isn't that hyperbolic growth… This is Kuhnian paradigm…

both comments in the last 24h

Whatever the AI, the point is valid and I had a similar train of thought reading TFA. This comment section took a different turn but hey, what can be used for good can be abused for bad. Gee whizz!