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

51–60 of 414 posts

Re: The Day the Telnet Died

#51

Post by wildzzz »

ieie3366 wrote: post #23
greyface- wrote: post #17

Earlier quoted context omitted.

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...

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.

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.

Re: The Day the Telnet Died

#52

Post by Aloha »

dragonfax wrote: post #43
direwolf20 wrote: post #39

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.

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.

Re: The Day the Telnet Died

#53

Post by charcircuit »

direwolf20 wrote: post #39
charcircuit wrote: post #36

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.

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

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

Re: The Day the Telnet Died

#55

Post by wiml »

dragonfax wrote: post #43
direwolf20 wrote: post #39

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.

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.

Re: The Day the Telnet Died

#56

Post by fhub »

ieie3366 wrote: post #23
greyface- wrote: post #17

Earlier quoted context omitted.

https://codeberg.org/inetutils/inetutils/commit/fa3245ac8c28...

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 how dodgy it was.

Re: The Day the Telnet Died

#57

Post by iamnothere »

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)

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.

Re: The Day the Telnet Died

#58

Post by klempner »

dragonfax wrote: post #43
direwolf20 wrote: post #39

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.

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.

Re: The Day the Telnet Died

#60

Post by esseph »

charcircuit wrote: post #53
direwolf20 wrote: post #39

Earlier quoted context omitted.

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

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

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.

Post reply on HN