If a user account on a Linux machine is compromised, clearly, all files owned by that user are compromised.

Unfortunately, if the compromised user also has sudo privileges, it seems that binary planting can be used to trivially gain the sudo password and therefore escalate the attack to root privileges (bad).

Are there any good defences against this attack, or is it generally accepted that root will be compromised if sudo is in use?

Previous question on a related note: zsh - fully expand binary path on <tab>

This does not solve the problem, because even if your shell .rc file is owned by root, it can be removed by the local user and replaced with one containing a malicious $PATH variable, or the keyboard shortcut to open a terminal could be replaced by a malicious one.


It is impossible to completely prevent such attacks, at least without any major system reengineering and a heavy burden on the user.

If an attacker has write access to your account, then the user can create a mock environment that hides all traces of the compromise to your eyes. The most obvious way is to use LD_PRELOAD to load a library that hides itself and whatever else the attacker has planted (this wouldn't work on statically linked binary, a more sophisticated wrapper is needed there).

The attack would remain visible to other users until the attacker has escalated to other accounts. So you could make a process running as root check the files on your account and report any change. The problem with this is that you'll be making a lot of legitimate changes; it's unlikely that you'd be able to notice an illegitimate change amongst the noise.

There is a way to contain the damage to your account, which is to require any privilege escalation to go through a fully trusted user interface. This would mean that:

  • Authentication as root must go through only processes that do not belong to the user and cannot be controlled by the user. In particular, no X11 interface.
  • You must have a way to identify the login prompt as genuine: otherwise the attacker could mock the trusted UI. There are two approaches for this.

    • Have a secure attention key, which cannot be rebound to another function by the user. Press the SAK to display a login prompt on a terminal that is not under the control of the user. This can be set up on some unices, but I'm unaware of a fully-fleshed solution that has undergone serious security review.
    • Have the system authenticate itself to the user, again through a user interface over which the user has no control. The authentication can be static, e.g. showing you a picture of your children; this is easy for you to verify but also easy to spoof in a targeted attack. The authentication can be dynamic, with the system showing you a one-time password that you verify on a separate trusted system; this requires that you have such a system (typically an OTP token).

Both approaches only work for local logins. You can't be sure of the path between you and the system when working remotely. And you can't use anything convenient like sudo, copy-pasting the command and so on; you fundamentally need to do something disruptive from a UI point of view, like switch to a different terminal.

Oh, and once the attacker is root, he can easily install a rootkit that makes it impossible to detect. Local attacks are common anyhow; if the attacker has compromised your account and this is an advanced attack (not necessarily the case if you merely left your terminal unattended), assume that the root account is compromised too.

  • Thanks, I'll try to get the SAK set up. I've set 'rbash --norc' as my login shell, as far as I can see this falls into the category of "cannot be controlled by the user", and is about the safest thing going in any case, so I'll use that for my ssh and gpg from now on, and maybe use that or a root login shell whenever I need root permissions (both of those by switching to a TTY console) – Ali Jan 29 '12 at 0:37
  • Changing shell is also useless if the chsh command can be used to change back. This is fixed by either putting your shell at /bin/rsh or just removing all other shells from /etc/shells and updating /etc/passwd to only use the remaining shell. – Ali Jan 29 '12 at 12:40
  • @Ali You can restrict chsh to root (on many systems, it's easily done through PAM: auth required pam_rootok.so in /etc/pam.d/chsh). – Gilles 'SO- stop being evil' Jan 29 '12 at 20:33

The commands that a user can sudo can be limited in the sudo configuration. Sudo does not need to be equivalent to root.

Otherwise, I think you answered your own question -- if I have the keys to the henhouse, and Mr. Fox gets my keys, then I'm going to be able to eat all the chickens. There is no solution to that.

However, there are at least tools like tripwire or ossec to alert you when a rootkit has been installed. See this for some details.

  • On the majority of personal computers though it is the case that sudo=root, the culture for the most part assumes it. – Ali Jan 28 '12 at 23:16
  • It's clear that many don't see privilege escalation as something that should be accepted as a given though, and this contradicts my previous comment. – Ali Jan 28 '12 at 23:20
  • Finally, this is not a problem that is unfixable by nature, all that is required to fix this is assurance that any sudo invocation goes to the intended binary, and that a minimum of root privilege is required to modify that behaviour. Come to think of it, running a non-configurable window manager and non-configurable shell for sudo usage would solve this problem... I think I just answered my own question – Ali Jan 28 '12 at 23:24

Tripwire/AIDE/Samhain are working approaches for HIDS (host based intrusion detection systems). Some of them can be combined with central server parts so the signatures are not on the local computer (e.g. Beltane for Samhain).

Another approach - which I use on my workstation - where I do change files quite frequently is to check whether your OS files are still consistent.

I do this by doing a full rpm -Va - put the output into a file and compare that output with the next run. That way I will capture binary changes that are not part of the OS-patch-changes (I turn on gpg verification as well).

For both methods there are ways to circumvent them...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.