Hacker News Reader

Comment by zrth | Hacker News Reader

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?

View on HN

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.

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.

Reply on news.ycombinator.com