| ▲ | charcircuit 20 hours ago |
| 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. |
|
| ▲ | derefr 19 hours ago | parent | next [-] |
| Oldschool telnetd didn’t actually run as root; rather, it just set up a PTY for the incoming socket to talk to, and then fork-exec’ed a /bin/login subprocess to live inside that pty. /bin/login is setuid-root, so it’s “where the security lived.” I think we all collectively decided that that was a bad idea at some point — probably because /bin/login was never designed under the assumption that it would have to deal with arbitrary binary network traffic being thrown at it (it really only expects keyboard input.) So we switched to doing auth directly in our network daemons, since at least then “people who are aware the code is network-facing” would be maintaining it. |
|
| ▲ | nine_k 20 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | accrual 19 hours ago | parent | next [-] | | > 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. | |
| ▲ | spott 19 hours ago | parent | prev | next [-] | | Does ssh need to allow root logins? Sshing as a regular user and then sudo to root works 95% of the time… | | |
| ▲ | jmb99 16 hours ago | parent [-] | | How does SSH become an arbitrary user without effective root? | | |
| ▲ | nine_k 14 hours ago | parent [-] | | 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. |
|
| |
| ▲ | charcircuit 19 hours ago | parent | prev [-] | | 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. | | |
| ▲ | nine_k 19 hours ago | parent [-] | | You are thinking 20 years ahead. In 1995 most servers were still pets, not cattle. |
|
|
|
| ▲ | ikmckenz 16 hours ago | parent | prev | next [-] |
| OpenSSH has been moving quite quickly in the direction of multiple, privilege separated processes, each also heavily sandboxed with pledge and unveil |
|
| ▲ | direwolf20 20 hours ago | parent | prev [-] |
| Literally how else is a remote login daemon supposed to work though? |
| |
| ▲ | dragonfax 20 hours ago | parent | next [-] | | 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. | | |
| ▲ | acdha 20 hours ago | parent | next [-] | | 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. | | |
| ▲ | accrual 19 hours ago | parent [-] | | Yes, but changing users is a function of the shell (or maybe more specifically /usr/bin/login), not the SSH daemon. | | |
| ▲ | acdha 8 hours ago | parent [-] | | 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. |
|
| |
| ▲ | klempner 20 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | samlinnfer 15 hours ago | parent [-] | | Well obviously each user just needs to run their own telnet daemon, on their own port of course. |
| |
| ▲ | 19 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | wiml 20 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | Aloha 20 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | 20 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | 20 hours ago | parent | prev [-] | | [deleted] |
| |
| ▲ | charcircuit 20 hours ago | parent | prev [-] | | The remote daemon has its own account and is given a privilege that allows it to connect a network socket to a pseudo terminal. | | |
| ▲ | direwolf20 20 hours ago | parent | next [-] | | Those are already unprivileged operations, but how does it start the initial process in that terminal with the correct privileges for a different user? | | | |
| ▲ | esseph 20 hours ago | parent | prev [-] | | 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. | | |
| ▲ | charcircuit 19 hours ago | parent [-] | | 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. | | |
| ▲ | esseph 19 hours ago | parent [-] | | > Breaching the daemon only allows for the attacker to get access to the login Yes, but potentially any login. See the problem? If you compromise the gatekeeper, you are now the keymaster. Or whatever :) | | |
| ▲ | charcircuit 17 hours ago | parent [-] | | I'll admit it is still problematic. But at least there is only 1 gatekeeper instead of 2. | | |
| ▲ | jmb99 16 hours ago | parent [-] | | How is that better? | | |
| ▲ | charcircuit an hour ago | parent [-] | | You can focus all of your energy into strengthening and testing a single point of the system instead of having to do it for many. | | |
| ▲ | esseph 17 minutes ago | parent [-] | | You're grasping for straws a bit here. This is already done for ssh as the defacto remote access mechanism for a very long time. |
|
|
|
|
|
|
|
|
