4 ms·

it's not more secure/less secure if you enable root over pubkey only. I mean if I can login with a user that has sudo rights (probably with no password, the def

by merb 9y ago

it's not more secure/less secure if you enable root over pubkey only. I mean if I can login with a user that has sudo rights (probably with no password, the default on most cloud providers) there is no real benefit in having a user called ubuntu or centos that can login and gain full sudo rights than using root directly.

pecg 9y ago
If the password used for the user, in the remote machine, is different from that of the machine he/she is connecting from, the attacker will not be able to gain root access, even if the account has permission to escalate priviledges.
- inetknght 9y ago
  I don't see how the authentication used for a user on a local machine has anything to do with the authentication of a user on a remote machine unless both are using the same domain authentication (RADIUS, Active Directory, etc). Even then, there can be cache involved.
  - closeparen 9y ago
    There could be a local compromise that exposes the SSH keys (for login) but not the remote password (for sudo).
    - inetknght 9y ago
      My parent comment indicates that the password needs to be different. Your comment does not support that. First, sudo should not be cached for this very reason. Second, agent caching should never be enabled for this very reason. Third, agent forwarding should never be enabled for this very reason. Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable.
      - merb 9y ago
        > Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable. which most often is not the default on vps/root/clouds, that's basically my point. if you use sudo, use it with a password.
    - deleted 9y ago
      [deleted]
- geofft 9y ago
  The attacker can still do things like - attach to an existing screen session that has an existing process under sudo inside it - edit .bashrc to alias sudo to something that records the password, then come back later - spawn a background process that waits for the user to run sudo, then opens the pty and uses TIOCSTI to type commands at it Also, if the attacker actually has control over the sysadmin's local machine, they can do a lot more damage, like any of the above locally, or - send an email from the admin's account to the team saying "Hi, I'm trying to run this command but I left my RSA token at home, can anyone help?" - add a browser extension that rewrites all <pre> tags to include a https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste -style attack - commit to code or configuration-management repos adding a back door and trigger a deployment None of these are technically difficult attacks. Requiring a separate sudo password might slow down a script kiddie, but that's about it.
  - 616c 9y ago
    Thanks, kind stranger. You taught even me some I didn't know!
StreamBright 9y ago
Some admins allow only certain command to be executed with sudo vs root can execute anything with root.
- geofft 9y ago
  I have never seen anyone implement such a policy for sysadmins that actually prevents an attacker from running arbitrary commands. As soon as you permit running e.g. vi on some file, you can just shell out from vi. Or if you can sudo apt-get install, you can downgrade a package to a vulnerable version and then exploit it. Or if you can sudo tcpdump, you can write a dump file to /etc/cron.d and send a valid cron command surrounded by newlines over the network. Or lots of other things. sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.
  - skissane 9y ago
    10+ years ago I was setting up a new web server, Apache running on a Linux box. I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team. I asked for root access (via sudo) so I could do stuff like restart Apache. The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands. So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root. I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it. So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache. When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it. When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.

by merb 9y ago

pecg 9y ago

If the password used for the user, in the remote machine, is different from that of the machine he/she is connecting from, the attacker will not be able to gain root access, even if the account has permission to escalate priviledges.

inetknght 9y ago
I don't see how the authentication used for a user on a local machine has anything to do with the authentication of a user on a remote machine unless both are using the same domain authentication (RADIUS, Active Directory, etc). Even then, there can be cache involved.
- closeparen 9y ago
  There could be a local compromise that exposes the SSH keys (for login) but not the remote password (for sudo).
  - inetknght 9y ago
    My parent comment indicates that the password needs to be different. Your comment does not support that. First, sudo should not be cached for this very reason. Second, agent caching should never be enabled for this very reason. Third, agent forwarding should never be enabled for this very reason. Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable.
    - merb 9y ago
      > Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable. which most often is not the default on vps/root/clouds, that's basically my point. if you use sudo, use it with a password.
  - deleted 9y ago
    [deleted]
geofft 9y ago
The attacker can still do things like - attach to an existing screen session that has an existing process under sudo inside it - edit .bashrc to alias sudo to something that records the password, then come back later - spawn a background process that waits for the user to run sudo, then opens the pty and uses TIOCSTI to type commands at it Also, if the attacker actually has control over the sysadmin's local machine, they can do a lot more damage, like any of the above locally, or - send an email from the admin's account to the team saying "Hi, I'm trying to run this command but I left my RSA token at home, can anyone help?" - add a browser extension that rewrites all <pre> tags to include a https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste -style attack - commit to code or configuration-management repos adding a back door and trigger a deployment None of these are technically difficult attacks. Requiring a separate sudo password might slow down a script kiddie, but that's about it.
- 616c 9y ago
  Thanks, kind stranger. You taught even me some I didn't know!

StreamBright 9y ago

Some admins allow only certain command to be executed with sudo vs root can execute anything with root.

geofft 9y ago
I have never seen anyone implement such a policy for sysadmins that actually prevents an attacker from running arbitrary commands. As soon as you permit running e.g. vi on some file, you can just shell out from vi. Or if you can sudo apt-get install, you can downgrade a package to a vulnerable version and then exploit it. Or if you can sudo tcpdump, you can write a dump file to /etc/cron.d and send a valid cron command surrounded by newlines over the network. Or lots of other things. sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.
- skissane 9y ago
  10+ years ago I was setting up a new web server, Apache running on a Linux box. I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team. I asked for root access (via sudo) so I could do stuff like restart Apache. The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands. So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root. I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it. So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache. When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it. When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.