Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

71–80 of 414 posts

Re: The Day the Telnet Died

#71
post #31

Earlier quoted context omitted.

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…

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

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!

Re: The Day the Telnet Died

#72
post #50

Earlier quoted context omitted.

1. Start with root to bind the port below 1024. 2. give up root because you don't need it any further. 3. Only accept non-root logins 4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

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

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

Re: The Day the Telnet Died

#73
post #56

Earlier quoted context omitted.

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.

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

> a well known LLM agent

Which one?

Re: The Day the Telnet Died

#74

Earlier quoted context omitted.

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

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

The kernel could authenticate the user before starting it.

Re: The Day the Telnet Died

#75
post #51

Earlier quoted context omitted.

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

unless it doesn’t matter if it’s evesdropped

Traffic could be tampered as well.

Re: The Day the Telnet Died

#77

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)

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

Re: The Day the Telnet Died

#78
post #47

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

What do you think proper architecture would be, given that ssh needs a capability to let root logins? I suppose it could be via a proper PAM module, which is widely supported. Too bad the first PAM RFC was published about the same time the first be version of ssh was released.

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.

Re: The Day the Telnet Died

#79

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)

nethack.alt.org still maintains a telnet server!

Re: The Day the Telnet Died

#80

Earlier quoted context omitted.

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

1. Start with root to bind the port below 1024. 2. give up root because you don't need it any further. 3. Only accept non-root logins 4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

[deleted]
Post reply on HN