Live data from Hacker News

The Day the Telnet Died

labs.greynoise.io

201–210 of 414 posts

Re: The Day the Telnet Died

#201

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.

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.

Well obviously each user just needs to run their own telnet daemon, on their own port of course.

Re: The Day the Telnet Died

#202
post #195

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)

telnet lambda.moo.mud.org 8888

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.

Re: The Day the Telnet Died

#203

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)

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…

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.

Re: The Day the Telnet Died

#204
post #180

Earlier quoted context omitted.

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.

How on god’s green earth is `sudo apt install telnet` sufficiently challenging to be a driving factor to creating your own distro??

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.

Re: The Day the Telnet Died

#205

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)

[deleted]

Re: The Day the Telnet Died

#206

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)

From ChangeLog:

    * telnetd/utility.c (getterminaltype): Change the
      name `user_name' to `uname', as the former shadows a precious
     and global variable name.

Re: The Day the Telnet Died

#207

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

It's hilarious, especially given that I have memories of similar rlogin vulnerabilities -- various unixes being vulnerable to rlogin -l '-froot' in the 90s.

Re: The Day the Telnet Died

#208
post #181
post #111

Earlier quoted context omitted.

Does ssh need to allow root logins? Sshing as a regular user and then sudo to root works 95% of the time…

How does SSH become an arbitrary user without effective root?

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.

Re: The Day the Telnet Died

#209
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.

Re: The Day the Telnet Died

#210

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)

From ChangeLog: * telnetd/utility.c (getterminaltype): Change the name `user_name' to `uname', as the former shadows a precious and global variable name.

Congratulations! Now you've got yourself a precious and global(ly exploitable) vulnerability...
Post reply on HN