Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

Post reply on HN
Print view View original

281–290 of 414 posts

Re: The Day the Telnet Died

#281

Post by acdha »

accrual wrote: post #72
acdha wrote: post #50

Earlier quoted context omitted.

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

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

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

Re: The Day the Telnet Died

#282

Post by gspr »

forty wrote: post #238
gspr wrote: post #228

Earlier quoted context omitted.

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

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 m…

The hospital-plural-s: many places.

Roads: a lot more places than that.

The core of the analogy holds.

Re: The Day the Telnet Died

#283

Post by Balinares »

ajross wrote: post #138
pkaeding wrote: post #137

Earlier quoted context omitted.

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

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

I read it as a clear port 23 block.

Re: The Day the Telnet Died

#284

Post by thrance »

trebligdivad wrote: post #24

Why are people still using telnet across the internet in this century? Was this _all_ attack traffic? (OK, I know one ancient talker that uses it - but on a very non-standard port so a port 23 block wouldn't be relevant)

To play DOOM.

  telnet doom.w-graj.net 666

Re: The Day the Telnet Died

#285

Post by RupertSalt »

Kim_Bruning wrote: post #280
RupertSalt wrote: post #275

Earlier quoted context omitted.

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-trus…

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? Though ... I suppose by now a switch to port 22 could make sense.

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

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

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

   Port Assignment

      When used for remote user access to service hosts (i.e., remote
      terminal access) this protocol is assigned server port 23
      (27 octal).  That is L=23.
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.

Re: The Day the Telnet Died

#286

Post by jgalt212 »

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

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

Re: The Day the Telnet Died

#287

Post by 1718627440 »

prmoustache wrote: post #278
1718627440 wrote: post #243

Earlier quoted context omitted.

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

Many companies have been preventing its execution or removing the package by default for a number of years. Also most linux containers do not ships with such binaries to save on img size and reduce vuln management overhead.

> to save on img size

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

Re: The Day the Telnet Died

#288

Post by Quarrel »

RupertSalt wrote: post #279
qingcharles wrote: post #262

Earlier quoted context omitted.

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.

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…

> /etc/hosts.equiv

Ah, the memories.

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

Re: The Day the Telnet Died

#289

Post by da_chicken »

RupertSalt wrote: post #285
Kim_Bruning wrote: post #280

Earlier quoted context omitted.

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? Though ... I suppose by now a switch to port 22 could make sense.

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers. The end of RFC854, the very last paragraph, states: https://datatracker.ietf.org/doc/html/rfc854 Port Assignment When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port 23 (27 octal). That is L=…

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

Re: The Day the Telnet Died

#290

Post by trashb »

miki123211 wrote: post #252
NitpickLawyer wrote: post #216

Earlier quoted context omitted.

> 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…

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.

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.

Post reply on HN