Hacker News Reader

Comment by icebraining | Hacker News Reader

they'd have to guess my password for sudo access.

SSH to your account, add an alias to sudo in .bashrc (or equivalent for your shell) that records the password in a hidden file before passing it to the real sudo.

View on HN

Is there a practical way to prevent this kind of attack? Also, what the name for this class of exploitation so I can read more?

Use the absolute path to any */sbin utilities :-)

Doesn't help much. Once the attacker took over the account, nothing you do or see can be assumed to be real.

For example, the attacker could inject a LD_PRELOAD library that redirects execve() calls from /usr/bin/sudo to a fake version of sudo.

You can't LD_PRELOAD on a SUID binary like sudo. That said, I agree with your main point - one should use a different account altogether.

I meant preloading it in the shell. The real /usr/bin/sudo would be never executed, so it wouldn't matter if it's suid or not.

How can you preload in the shell? Isn't it launched by sshd, which you can't configure?

You can't configure which shell is run, but you can usually configure the shell (in ~/.profile or a similar file).

Or, if the server is running Debian, you can set environment variables the .pam_environment file:

https://bugs.debian.org/761600

I don't think .profile runs before the shell is spawned, does it?

The .pam_environment one is interesting, thanks for the link.

You can still exec into a new shell, for example.

I'm not security pro, but I think the best way is to use a separate account that you'd login to directly (on the physical TTY or via SSH) just to run the root commands. Going through your regular account is always more dangerous if you assume it might be compromised.

By the way, this is why Microsoft invented the UAC prompt: rather than a password, which can be intercepted, it generates a window which (presumably) cannot, thanks to User Interface Privilege Isolation.

Reply on news.ycombinator.com