[HN Gopher] The Day the Telnet Died
___________________________________________________________________
The Day the Telnet Died
Author : pjf
Score : 480 points
Date : 2026-02-10 22:20 UTC (1 days ago)
(HTM) web link (www.labs.greynoise.io)
(TXT) w3m dump (www.labs.greynoise.io)
| adolph wrote:
| _The pattern points toward one or more North American Tier 1
| transit providers implementing port 23 filtering_
| RupertSalt wrote:
| Someone attempted to compromise my home router last week using
| CHARGEN. Can you imagine!
| direwolf20 wrote:
| Attempted to compromise, or just port scanned?
| RupertSalt wrote:
| 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.
| iberator wrote:
| 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...
| jwpapi wrote:
| it was just ai written thats why.. unexpectedly so from
| greynoise.
| taftster wrote:
| 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.
| roywiggins wrote:
| 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.
| taftster wrote:
| 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.
| roywiggins wrote:
| Oh, I have fond memories, I learned to touch-type playing
| MUDs.
| ksherlock wrote:
| 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.
| RonanSoleste wrote:
| I still used telnet today (had to). Unsure of the patching here.
| But its definitely locked down to a subset of internal use only.
| pbhjpbhj wrote:
| Embedded? Ancient? What sort of systems are you telnetting
| into?
| fennec-posix wrote:
| 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.
| Twisol wrote:
| > 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?
| MBCook wrote:
| 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?
| wbl wrote:
| Not at interconnect speeds
| Mixtape wrote:
| 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.
| MBCook wrote:
| 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.
| RupertSalt wrote:
| 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!
| Twisol wrote:
| 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.
| RupertSalt wrote:
| 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!
| Twisol wrote:
| > [...] 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...
| orangecsmud wrote:
| 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.
| spijdar wrote:
| 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. :-)
| breve wrote:
| > _MUDs do none of this._
|
| MOOs do.
| Laforet wrote:
| 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.
| davebranton wrote:
| Why would somebody read something that somebody couldn't be
| bothered to write? This article is AI slop.
| accrual wrote:
| What stood out as AI written? It felt like a well-written
| article by an SME to me.
| tripdout wrote:
| 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.
| throw10920 wrote:
| 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.
| nephihaha wrote:
| 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.
| gerdesj wrote:
| 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.
| Twisol wrote:
| 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.
| quotemstr wrote:
| 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.
| doubled112 wrote:
| 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.
| ktpsns wrote:
| 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.
| ozarkerD wrote:
| I discovered swaks recently, god I love that tool
| Animats wrote:
| So eleven years ago someone put a backdoor in the Telnet daemon.
|
| Who?
|
| Where's the commit?
| parl_match wrote:
| It wasn't a backdoor, just a very serious security bug.
| Congrats on jumping straight to conspiracy and paranoia,
| though.
| alt187 wrote:
| It's only a conspiracy and paranoia if it's wrong. 11 years
| ago was 2015.
| its_magic wrote:
| > GNU organization
|
| > giant security flaw
|
| Checks out.
| parl_match wrote:
| 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.
| greyface- wrote:
| https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...
| ieie3366 wrote:
| 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.
| avaer wrote:
| There's a famous XKCD about this: https://xkcd.com/2347/
|
| In this case the hero's name is apparently Simon Josefsson
| (maintainer).
| idiotsecant wrote:
| I feel like we should just start saying 2347. Everyone
| knows what you mean.
| AlienRobot wrote:
| https://xkcd.com/2347/
|
| Ah, someone beat me to it!
| direwolf20 wrote:
| 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.
| its_magic wrote:
| 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.
| nomel wrote:
| 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.
| db48x wrote:
| 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.
| its_magic wrote:
| I am the one doing it better. GNU software is slowly
| being deprecated on my system, starting with glibc.
| db48x wrote:
| So you're just changing which volunteers you depend on?
| That's really productive of you. Thank you for your
| service.
| account42 wrote:
| You can enslave yourself to Microslop if you prefer.
| acdha wrote:
| 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/pyth
| on-c...
| wildzzz wrote:
| 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.
| dec0dedab0de wrote:
| unless it doesn't matter if it's evesdropped
| FabHK wrote:
| Traffic could be tampered as well.
| nomel wrote:
| Sometimes that doesn't matter either. That _is_ the valid
| use case of a plain-text protocol like telnet: doesn 't
| matter.
| fhub wrote:
| 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.
| JCattheATM wrote:
| > a well known LLM agent
|
| Which one?
| accrual wrote:
| Not GP, but my local Ministral 3 14B and GPT-OSS 20B
| didn't catch anything unless I gave some hints.
| JCattheATM wrote:
| He says 'well known' so I assume Claude or GPT, I just
| don't get why he's being coy.
| fhub wrote:
| 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.
| icedchai wrote:
| Most 90's era software had zero tests. Nobody gave it a
| second thought.
| lmm wrote:
| Early '90s maybe. By the late '90s people knew tests were
| a good idea, and many even applied that in practice.
| pjc50 wrote:
| It can't be critical business software if the business to
| which it is critical isn't paying anything for it.
|
| /s
| its_magic wrote:
| 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.
| gzread wrote:
| Same here. It says please wait while verifying.
| its_magic wrote:
| 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.
| Arubis wrote:
| Telnet's cleartext and always has been. A backdoor seems like
| overkill.
| direwolf20 wrote:
| 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.
| mmooss wrote:
| > backdoor
|
| Do you mean that it's intentional? Why do you think so?
| trebligdivad wrote:
| 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)
| mcpherrinm wrote:
| As I understand it, greynoise is monitoring scanner traffic, so
| yes this would all be scans or attacks
| jaredsohn wrote:
| 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.)
| mmooss wrote:
| Connection failed
|
| Maybe we should give the kind person who hosts it a break.
| Try it out tomorrow. (Yes, I should have thought of that
| before I tried.)
| accrual wrote:
| 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.
| kalleboo wrote:
| It's still working over IPv6
| posperson wrote:
| 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.
| cbarrick wrote:
| ~~IIRC the blinkenlights telnet movies have been offline for
| a few years already.~~
| jaredsohn wrote:
| I connected a few times today to the IPv4 one. Have had no
| problems myself.
| iamnothere wrote:
| 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.
| mananaysiempre wrote:
| > 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.)
| iamnothere wrote:
| 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.
| mananaysiempre wrote:
| 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
| iamnothere wrote:
| 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.
| lambdaone wrote:
| You can use ssh with the None cipher, thus disabling
| encryption entirely while still using the rest of the
| protocol.
| ErroneousBosh wrote:
| Most people don't care about FCC rules.
|
| I'm breaking a tonne of FCC rules right now.
| mystraline wrote:
| 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.
| ErroneousBosh wrote:
| > 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?
| trebligdivad wrote:
| Yes but in many ways it's riskier to do that when you have
| a license from them.
| rcakebread wrote:
| One? All the talkers still use it and all the MUDs/MOOs etc.
| far out number the talkers.
| conesus wrote:
| N.U.T.S. 3.3.3 4eva! There was a NUTS 4, but about a decade
| too late.
| para_parolu wrote:
| Aardwolf works well from my work laptop. And I don't care if
| someone sees what I'm doing
| stenius wrote:
| 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.
| para_parolu wrote:
| 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.
| omegaham wrote:
| nethack.alt.org still maintains a telnet server!
| RupertSalt wrote:
| 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/
| 0xbadcafebee wrote:
| 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.
| taftster wrote:
| 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.
| emmelaich wrote:
| 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.
| ajross wrote:
| > 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.
| SAI_Peregrinus wrote:
| 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.
| ajross wrote:
| 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.
| SAI_Peregrinus wrote:
| I don't mean to imply it's _just_ the format, merely that
| they 're unrelated. Different file format, different
| trust model, different threat model. The point is that a
| device manufacturer or network administrator can trust
| all devices that have valid certs signed by their
| internal issuer, and create ways for devices to rotate
| host keys & request new certs.
| PhilipRoman wrote:
| >>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.
| ajross wrote:
| 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.
| PhilipRoman wrote:
| 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...
|
| They have ssh, but no proper key management
| 0xbadcafebee wrote:
| 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.
| ajross wrote:
| 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.
| Izkata wrote:
| Their original comment was referring to people ignoring
| the warning banner and connecting anyway when the host
| changes. Not that it doesn't exist.
| Fnoord wrote:
| > 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.
| watermelon0 wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
| Quarrel wrote:
| 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.
| myko wrote:
| I run a DikuMUD that users connect to using Telnet
|
| I really should update it to allow more secure options
| Fnoord wrote:
| > 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.
| fipar wrote:
| Or with telnet (the client)
| myko wrote:
| 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!
| conesus wrote:
| 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?
| myko wrote:
| ncmdu.net 9000 :)
|
| Pretty slow these days, hack 'n slash style game
| breve wrote:
| telnet lambda.moo.mud.org 8888
| dekhn wrote:
| 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.
| ErroneousBosh wrote:
| 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.
| dekhn wrote:
| 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.
| semyonsh wrote:
| How else would I connect to my BBS to play L.O.R.D. and check
| FidoNet.
| VadimPR wrote:
| One reason would be to play MUDs, which are very well and alive
| these days!
| thrance wrote:
| To play DOOM. telnet doom.w-graj.net 666
| Suzuran wrote:
| Some of us still run historical systems for preservation's
| sake.
| catskull wrote:
| 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!
| ekropotin wrote:
| I did this too, lol
| bentcorner wrote:
| 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.
| mmh0000 wrote:
| 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
| lacunary wrote:
| telnet + shijack = good times
| charcircuit wrote:
| 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.
| direwolf20 wrote:
| Literally how else is a remote login daemon supposed to work
| though?
| dragonfax wrote:
| 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.
| acdha wrote:
| 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.
| accrual wrote:
| Yes, but changing users is a function of the shell (or
| maybe more specifically /usr/bin/login), not the SSH
| daemon.
| acdha wrote:
| 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.
| Aloha wrote:
| 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.
| wiml wrote:
| 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.
| klempner wrote:
| 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.
| samlinnfer wrote:
| Well obviously each user just needs to run their own
| telnet daemon, on their own port of course.
| charcircuit wrote:
| The remote daemon has its own account and is given a
| privilege that allows it to connect a network socket to a
| pseudo terminal.
| esseph wrote:
| 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.
| charcircuit wrote:
| 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.
| esseph wrote:
| > 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 :)
| charcircuit wrote:
| I'll admit it is still problematic. But at least there is
| only 1 gatekeeper instead of 2.
| jmb99 wrote:
| How is that better?
| charcircuit wrote:
| 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.
| esseph wrote:
| 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.
| direwolf20 wrote:
| Those are already unprivileged operations, but how does it
| start the initial process in that terminal with the correct
| privileges for a different user?
| charcircuit wrote:
| The kernel could authenticate the user before starting
| it.
| direwolf20 wrote:
| How does it do that?
| charcircuit wrote:
| There are many ways from passkeys to SAML. Though for
| complex methods we may want a dedicated services outside
| the kernel.
| direwolf20 wrote:
| How does that service get launched with the privilege to
| switch to any user?
| charcircuit wrote:
| The kernel can start a process with any user it wants.
| The user doesn't have to switch during the process's
| life.
| nine_k wrote:
| 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.
| accrual wrote:
| > 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.
| charcircuit wrote:
| 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.
| nine_k wrote:
| You are thinking 20 years ahead. In 1995 most servers were
| still pets, not cattle.
| spott wrote:
| Does ssh need to allow root logins?
|
| Sshing as a regular user and then sudo to root works 95% of
| the time...
| jmb99 wrote:
| How does SSH _become_ an arbitrary user without effective
| root?
| nine_k wrote:
| 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.
| derefr wrote:
| 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.
| ikmckenz wrote:
| OpenSSH has been moving quite quickly in the direction of
| multiple, privilege separated processes, each also heavily
| sandboxed with pledge and unveil
| jopython wrote:
| This is about Telnetd. Not telnet itself.
| saulpw wrote:
| ...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).
| accrual wrote:
| 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.
| RupertSalt wrote:
| 1. TELNET is an IETF-standard protocol defined by RFCs.
| 2. Telnet is a well-known port assigned by the IANA (tcp/23).
| 3. telnet is a client program, originated on Unix, available on
| many systems, and likely from a quite homogeneous codebase.
| 4. telnetd is a server program, also originated on Unix for the
| purpose of implementing Telnet protocol as a login server. Also
| a homogeneous codebase or two.
|
| TFA is about items 2 and 4, and 1/3 are completely unrelated.
|
| IIRC, the _only_ traffic that was monitored and detected here
| is the scanning. The vulnerability scanners that try and
| detect, for better or worse, what someone 's running on port
| 23, fingerprint it, and figure out if it's a vulnerability.
|
| Interestingly, filtering port 23 only mitigates the CVE by
| happenstance. It is merely by convention that telnetd runs on
| port 23, so that people can use it to log in remotely. There is
| no constraint that requires port 23. Any other service could
| usurp 23/tcp for itself if the admin decrees it. So, filtering
| port 23 is an effective mitigation for the defaults of someone
| running a vulnerable server on the standard port. But it is not
| a panacea, and it doesn't prevent anyone from using the telnetd
| server, or the telnet client, except for port 23.
|
| But it also prevents you from offering any service on port
| 23/tcp, lest it be filtered. You wouldn't want to run a web
| server, sshd, a MUD, or anything else, because your
| connectivity would be negatively impacted for this reason. (The
| common experience is that a lot of Windows SMB/NetBIOS ports
| are blocked, and SMTP and port 80, on a lot of consumer ISPs,
| although this is contrasting the ISP situation to Tier-1
| transit carriers now.)
| otterley wrote:
| 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.
| fsmv wrote:
| Your cookie banner is very inconvenient and made me leave your
| website and not read the article
| keyle wrote:
| 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).
| accrual wrote:
| It's also not DNS!
| its_magic wrote:
| Or Windows, for a change!
| larholm wrote:
| Or Notepad, for a change!
| tosti wrote:
| Argument injection can happen in any programming language where
| you can concatenate strings and call something with the result.
| erichanson wrote:
| I used to telnet into my POP3 account and check email by
| protocol. Shucks.
| neom wrote:
| 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.
| peteforde wrote:
| 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.
| ycombinatrix wrote:
| >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.
| Quarrel wrote:
| 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.
| anitil wrote:
| 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
| Telemakhos wrote:
| 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.
| mlyle wrote:
| It's hilarious, especially given that I have memories of
| similar rlogin vulnerabilities -- various unixes being
| vulnerable to rlogin -l '-froot' in the 90s.
| wellf wrote:
| 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.
| itintheory wrote:
| I'm a fan of 'nc' / netcat for this purpose. It's small,
| quick, and can send or receive over TCP or UDP.
| qingcharles wrote:
| 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.
| RupertSalt wrote:
| 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.
| Quarrel wrote:
| > /etc/hosts.equiv
|
| Ah, the memories.
|
| cat '+ +' >> /etc/hosts.equiv
| RupertSalt wrote:
| Ah, I have no memory of such a command, so I must be
| getting old!
| roryirvine wrote:
| 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.
| icedchai wrote:
| 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.
| lofaszvanitt wrote:
| Who actually uses the tectia ssh client instead of openssh?
| tokyobreakfast wrote:
| 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.
| p_ing wrote:
| Thats what the mystery exceptions for the Open Group macOS UNIX
| certification was for!
| epcoa wrote:
| telnet has never been in POSIX though.
| p_ing wrote:
| It's a joke and a poke that macOS isn't certified UNIX as
| shipped.
| RupertSalt wrote:
| 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.
| paulddraper wrote:
| There's no UNIX requirement for telnet.
|
| Ubuntu does not include it by default (starting 16.04?). Most
| most distros don't.
| tokyobreakfast wrote:
| 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.
| mmh0000 wrote:
| 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.
| tokyobreakfast wrote:
| > 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.
| theParadox42 wrote:
| It seems rather typical for Apple. The removal of the
| headphone jack obsoleted thousands of consumer devices.
| its_magic wrote:
| 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.
| jmb99 wrote:
| How on god's green earth is `sudo apt install telnet`
| sufficiently challenging to be a driving factor to
| creating your own distro??
| its_magic wrote:
| 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.
| RupertSalt wrote:
| 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.
| its_magic wrote:
| > 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.
| RupertSalt wrote:
| 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.
| its_magic wrote:
| > 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.
| paulddraper wrote:
| The easiest way to make your own "distro" is apt-get
| install stuffiwant...
| paulddraper wrote:
| 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.
| anthk wrote:
| Netcat works as a telnet client. GAWK can do that too with a
| dumb loop. So can con(1) under 9front.
| 1718627440 wrote:
| 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.
| badc0ffee wrote:
| There's always nc hostname 23 unless you need authentication
| Sparkyte wrote:
| Between you and me telnet is not dead. Sometimes I use it to
| probe a port to verify it is working.
| otterley wrote:
| 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.
| Fnoord wrote:
| 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)
| snazz wrote:
| 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.)
| AnonHP wrote:
| 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.
| ajross wrote:
| 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.
| pkaeding wrote:
| 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.
| ajross wrote:
| 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.
| Balinares wrote:
| I read it as a clear port 23 block.
| emmelaich wrote:
| > _started blocking telnet 's default port_
|
| But that's 23 and smtp is 25.
| jonprobably wrote:
| SMTP has and is almost blocked everywhere to dissuade spam.
| dwedge wrote:
| 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
| einr wrote:
| 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.
| mmh0000 wrote:
| 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.
| EE84M3i wrote:
| 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?
| swinglock wrote:
| Because it's there.
| prmoustache wrote:
| It hasn't for the most part of the last 2 decades.
| 1718627440 wrote:
| 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.
| prmoustache wrote:
| 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.
| 1718627440 wrote:
| > to save on img size $ ls --human
| --size --dereference $(which telnet) 144K
| /usr/bin/telnet
| prmoustache wrote:
| 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.
| alphager wrote:
| Telnet client is an optional feature in Windows that
| needs to be enabled/installed.
| einr wrote:
| 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.
| 1718627440 wrote:
| 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.
| degamad wrote:
| 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.
| prmoustache wrote:
| You don't even need netcat or socat for that, probing
| /dev/tcp/<host>/<port> from the shell is enough.
| hibbelig wrote:
| Telnet was available in the 90s. I reckon /dev/tcp is way
| more recent. GP did say a long time ago.
| geocar wrote:
| 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.
| SoftTalker wrote:
| 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.
| indymike wrote:
| Same reason that people use vi. It's always there.
| linuxftw wrote:
| In the days of yore, Windows had telnet installed. Most
| hackers used telnet in the 90's and early 2000's.
| teddyh wrote:
| 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.
| acters wrote:
| 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.
| fragmede wrote:
| who's hand rolling code anymore these days though?
| 1718627440 wrote:
| 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?
| dudefeliciano wrote:
| 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.
| rballpug wrote:
| port 22 2FA
| est wrote:
| 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`
| VladVladikoff wrote:
| 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.
| josteink wrote:
| 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.
| VladVladikoff wrote:
| Damn :(
| virgulino wrote:
| 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.
| acters wrote:
| So basically the same as censorship because that is the exact
| same thing blocking ports does.
| fragmede wrote:
| 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?
| oaiey wrote:
| 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
| gspr wrote:
| 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.
| forty wrote:
| 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?
| gspr wrote:
| All I'm saying is that the only right place to fix this
| is at the hospital. Not at the roads leading to it.
| da_chicken wrote:
| 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.
| forty wrote:
| 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
| dizhn wrote:
| I run telnetd on 2323 because I don't want hackers to
| find it.
| gspr wrote:
| The hospital-plural-s: many places.
|
| Roads: a lot more places than that.
|
| The core of the analogy holds.
| zh3 wrote:
| 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_reinforce
| d...
|
| https://www.theconstructionindex.co.uk/news/view/raac-
| crisis...
|
| https://www.theguardian.com/education/2023/aug/31/what-is-
| ra...
| PunchyHamster wrote:
| 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
| 7bit wrote:
| Censorship is one of these words that get slapped on
| anything.
|
| Filtering one port is not censorship. Not even close.
| trashb wrote:
| > 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.
| citrin_ru wrote:
| 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.
| _ink_ wrote:
| Probably Tier 1 providers have some insight on this.
| sznio wrote:
| These are the institutions I would most expect to do that.
|
| Well, maybe not a bank.
| NitpickLawyer wrote:
| > 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?
| RulerOf wrote:
| 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.
| tosti wrote:
| 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.
| ncruces wrote:
| This is not an ISP. It's a Tier 1 transit provider.
| tosti wrote:
| 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.
| sophacles wrote:
| My ISP (AT&T) _is_ a tier 1 transit provider.
| PunchyHamster wrote:
| 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
| miki123211 wrote:
| 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.
| tosti wrote:
| 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.
| trashb wrote:
| 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.
| allknowingfrog wrote:
| 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.
| Sohcahtoa82 wrote:
| You've got it wrong. It doesn't have to be HTTP[S]
| traffic.
|
| Reverse proxies can disambiguate based on the SNI. I
| could run telnetd on port 23, but have port 23 firewalled
| off, and have my reverse proxy listening on port 443 with
| TLS forward anything going to telnet.mydomain.com to
| telnetd. Obviously, my client would need to support that,
| but a client-side proxy could easily handle that just as
| well.
| VadimPR wrote:
| 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.
| RupertSalt wrote:
| 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.
| Kim_Bruning wrote:
| 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.
| RupertSalt wrote:
| 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.
|
| I would say that by the letter of the law, and by
| longstanding convention, that port 23/tcp is given to
| telnetd type login servers. A server listening on port 23
| is expected to accept login credentials and furnish a
| shell or some management interface that affects the host
| itself. That someone would log in as a terminal user and
| perform computing tasks.
|
| 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.
| da_chicken wrote:
| Boy, wait until I tell you what happened with http!
| RupertSalt wrote:
| 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!
| simlevesque wrote:
| I don't understand how playing a MUD doesn't fit the
| definition of "remote user access to service hosts".
| Kim_Bruning wrote:
| You mean something like this?
| mudplayer:x:1001:1001:MUD
| Player:/home/mudplayer:/usr/games/adventure
| kps wrote:
| > 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.
| RupertSalt wrote:
| 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...
| FEELmyAGI wrote:
| > 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
| RupertSalt wrote:
| 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.
| metroholografix wrote:
| 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.
| ordu wrote:
| _> 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.
| RupertSalt wrote:
| 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.
| unethical_ban wrote:
| Yes, and sftp and scp should not operate on port 22
| because that isn't proper, interactive SSH!
| sophacles wrote:
| > 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.
| mikkupikku wrote:
| Hosted roguelikes have been using ssh for at least 15
| years. It's probably time for MUD folks to consider this.
| Suzuran wrote:
| 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.
| varenc wrote:
| 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?)
| Suzuran wrote:
| If I am rewriting the network stack or making other
| substantial changes, that defeats the purpose of
| historical preservation.
| RupertSalt wrote:
| 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?
| Suzuran wrote:
| I meant rewriting it for IPv6 instead of IPv4.
| Sohcahtoa82 wrote:
| > 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.
|
| This is still true, though 5-10 minutes is slightly
| pessimistic. Source: https://youtu.be/6uSVVCmOH5w
|
| TL;DW - Guy installs XP and makes it internet accessible,
| only takes 15 minutes before the first malware appears on it.
| pjc50 wrote:
| 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.
| gzread wrote:
| Not by tier 1 transit providers. You pay those to deliver
| your packets, no matter what.
| worksformeintx wrote:
| I can connect with the GNU telnet client via the Spectrum ISP
| to servers in both Seattle and the Netherlands.
| RupertSalt wrote:
| 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.
| ericpauley wrote:
| This simply isn't happening, and we have the data to prove it:
| https://www.terracenetworks.com/blog/2026-02-11-telnet-routi...
| virgulino wrote:
| > 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
| varenc wrote:
| 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.
| pavelstoev wrote:
| 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."
| RupertSalt wrote:
| 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?
| achillean wrote:
| There will be some honeypots in this data but this is a
| start:
|
| https://www.shodan.io/search/report?query=product%3Atelnetd+.
| ..
| pigggg wrote:
| More likely a specific botnet had it's c2 or telnet scanning
| report endpoint go down / get nulled on Jan 14th.
| achillean wrote:
| 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.
| VladVladikoff wrote:
| 77k hosts with port 23 open
| https://www.shodan.io/search?query=telnet
| achillean wrote:
| 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/
| digitalPhonix wrote:
| 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)
| naniwaduni wrote:
| From ChangeLog: * telnetd/utility.c
| (getterminaltype): Change the name `user_name' to
| `uname', as the former shadows a precious and global
| variable name.
| rob74 wrote:
| Congratulations! Now you've got yourself a precious and
| global(ly exploitable) vulnerability...
| ky3 wrote:
| 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?
| anonymousiam wrote:
| 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.
| ubixar wrote:
| 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.
| Gigachad wrote:
| Stop spamming AI slop
| ubixar wrote:
| ?
| jcattle wrote:
| 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)
| 0123456789ABCDE wrote:
| 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
| tosti wrote:
| 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!
| atoav wrote:
| Ah. Telnet. My oscilloscope still talks telnet, and this is the
| reason why that type of equipment is on an isolated net.
| jgalt212 wrote:
| > 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
| pjf wrote:
| 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?
| nubinetwork wrote:
| 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.
| teddyh wrote:
| Time to switch to SUPDUP!
| fweimer wrote:
| 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.)
| munch117 wrote:
| 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?
| pwg wrote:
| 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.
| munch117 wrote:
| 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.
| fortranfiend wrote:
| Telnet will live on, in areas it probably shouldn't like
| industrial controls systems, switch management, regulated
| industries, printing, etc.
___________________________________________________________________
(page generated 2026-02-11 23:01 UTC)