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.
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.
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
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.
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.
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!
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.
Those are already unprivileged operations, but how does it start the initial process in that terminal, the one that accepts a username and switches to that user?
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.
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.
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.
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.
> 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?
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.
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.
...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).
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.
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.
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).
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 many years ago and verified some instance of it still exists/works.)
One? All the talkers still use it and all the MUDs/MOOs etc. far out number the talkers.
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.
As I understand it, greynoise is monitoring scanner traffic, so yes this would all be scans or attacks
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'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.
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.
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.
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...
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.
There's a famous XKCD about this: https://xkcd.com/2347/
In this case the hero's name is apparently Simon Josefsson (maintainer).
https://xkcd.com/2347/
Ah, someone beat me to it!
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.
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!
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.
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.
Literally how else is a remote login daemon supposed to work though?
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, the one that accepts a username and switches to that user?
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
This is about Telnetd. Not telnet itself.
...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 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?
telnet isn't just for ... telnet.
.. or you can use SWAKS! For some odd reason telnet is becoming rare as an installed binary.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.
Your cookie banner is very inconvenient and made me leave your website and not read the article
telnet + shijack = good times
Why would somebody read something that somebody couldn't be bothered to write? This article is AI slop.
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?