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).
The Day the Telnet Died
61–70 of 414 posts
Re: The Day the Telnet Died
#62Why 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)
One? All the talkers still use it and all the MUDs/MOOs etc. far out number the talkers.
Re: The Day the Telnet Died
#63telnet 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.
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.
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.
Re: The Day the Telnet Died
#64Earlier 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.
Those are already unprivileged operations, but how does it start the initial process in that terminal with the correct privileges for a different user?
Re: The Day the Telnet Died
#65Earlier quoted context omitted.
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.)
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.)
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.
Re: The Day the Telnet Died
#66Earlier 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.
There's a famous XKCD about this: https://xkcd.com/2347/ In this case the hero's name is apparently Simon Josefsson (maintainer).
I feel like we should just start saying 2347. Everyone knows what you mean.
Re: The Day the Telnet Died
#67Earlier 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.
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
Re: The Day the Telnet Died
#68It's nice to not see C being blamed for once! ... Just good old lack of reasoning (which is most C's codebase downfall, agreeably).
It's also not DNS!
Re: The Day the Telnet Died
#69The 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.
> 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.
Re: The Day the Telnet Died
#70Earlier 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.
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 peo…
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.