5 ms·
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?
by zrth 9y ago
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?
- daimrod 9y agoUse the absolute path to any */sbin utilities :-)
- jwilk 9y agoDoesn'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.
- icebraining 9y agoYou 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.
- jwilk 9y agoI 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.
- icebraining 9y agoHow can you preload in the shell? Isn't it launched by sshd, which you can't configure?
- jwilk 9y agoYou 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 https://bugs.debian.org/761600
- icebraining 9y agoI don't think .profile runs before the shell is spawned, does it? The .pam_environment one is interesting, thanks for the link.
- lvh 9y agoYou can still exec into a new shell, for example.
- icebraining 9y agoI'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.