HN

Comments (334)

• willmarquis
  What strikes me about this isn't telnet itself—it's the quiet normalization of carrier-level protocol filtering as an acceptable solution to security problems.We've been here before: SMTP port 25 got similar treatment in the early 2000s to combat spam botnets. The difference is that blocking residential outbound 25 had a reasonable argument (legitimate mail servers shouldn't run on dynamic IPs anyway). Blocking port 23 wholesale is different—it's treating a protocol vulnerability by eliminating the protocol's reachability, rather than fixing the vulnerable implementations.The end-to-end principle used to mean that the network was a dumb pipe and intelligence lived at endpoints. Each time we add carrier-level filtering "for security," we're trading that architectural principle for short-term harm reduction. Sometimes that's the right call. But we should be honest that this is a one-way ratchet—once ISPs are in the business of deciding which ports you can use, there's always another CVE, another botnet, another "good reason" to add to the blocklist.The IPv6 workaround mentioned upthread is telling: the filtering seems to only apply to v4 because that's where the scanning happens. Which means this isn't really about protecting endpoints from vulnerable telnetd—it's about reducing scan traffic and abuse complaints. Understandable from an operational perspective, but let's call it what it is.For the MUD and historical preservation folks: this is your cue to move to TLS-wrapped connections or SSH tunnels, not because it's technically necessary, but because the writing has been on the wall for 20 years that cleartext protocols on well-known ports would eventually get squeezed out.
• munch117
  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 -- What's telnetd doing differently? Is it invoking login via a shell?
• Menu

  virgulino
  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.
• Menu

  Quarrel
  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.testor> USER='-f root' telnet -a server.testSurvive 11 years.
• fweimer
  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.)
• Menu

  AnonHP
  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.
• Menu

  trebligdivad
  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)
• Menu

  VladVladikoff
  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.
• Menu

  digitalPhonix
  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) What is the reason for a rename these days? If I saw that in a code review I’d immediately get annoyed (and probably pay more attention)
• Menu

  Twisol
  > 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?
• Menu

  peteforde
  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.
• Menu

  catskull
  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!
• Menu

  Animats
  So eleven years ago someone put a backdoor in the Telnet daemon.Who?Where's the commit?
• Menu

  keyle
  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).
• pjf
  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?
• Menu

  iberator
  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.orgjust works...
• Menu

  tokyobreakfast
  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.
• nubinetwork
  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.
• achillean
  Port 23 has decreased significantly over the past decade:https://i.imgur.com/tZoTWu6.pngStill seeing a sizable number of open ports but it's on the decline.
• snazz
  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.)
• anonymousiam
  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.
• Menu

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

  VladVladikoff
  77k hosts with port 23 open https://www.shodan.io/search?query=telnet
• est
  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`
• varenc
  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 I'm sure the port 23 telnet blocking will be coming to IPv6 soon though.
• pigggg
  More likely a specific botnet had it's c2 or telnet scanning report endpoint go down / get nulled on Jan 14th.
• Menu

  charcircuit
  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.
• Menu

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

  jopython
  This is about Telnetd. Not telnet itself.
• teddyh
  Time to switch to SUPDUP!
• Menu

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

  pavelstoev
  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.”
• Menu

  davebranton
  Why would somebody read something that somebody couldn't be bothered to write? This article is AI slop.
• anon
  undefined
• atoav
  Ah. Telnet. My oscilloscope still talks telnet, and this is the reason why that type of equipment is on an isolated net.
• jgalt212
  > 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
• fsmv
  Your cookie banner is very inconvenient and made me leave your website and not read the article
• Menu

  gerdesj
  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 .. or you can use SWAKS! For some odd reason telnet is becoming rare as an installed binary.
• lofaszvanitt
  Who actually uses the tectia ssh client instead of openssh?
• lacunary
  telnet + shijack = good times
• rballpug
  port 22 2FA
• Menu

  adolph
  The pattern points toward one or more North American Tier 1 transit providers implementing port 23 filtering
• gogasca
  [dead]
• Menu

  chenmx
  [dead]
• clarkqaq
  [dead]
• Menu

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