Preventing malware from sniffing the sudo password

Solution 1:

Once a piece of malware has gained access to a user's account, it can:

1. Create a bash alias (in the current shell, and in ~/.bashrc) to a command which fakes the [sudo] password for $USER: prompt, and steals the user's password.

alias sudo='echo -n "[sudo] password for $USER: " && \
            read -r password && \
            echo "$password" >/tmp/sudo-password'

2. Similarly, it can place an executable named sudo in ~/.bin, and modify the PATH variable to achieve the same effect: PATH="$HOME/.bin:$PATH"

3. Catch key presses through the X server, watch for the word sudo, then try the text between the next two Enter key presses as the password.

4. A similar thing can be done in any environment (the console, Wayland, X) using e.g. $LD_PRELOAD.

5. If malware infects a shell that uses sudo, and sudo caches credentials, the malware can continouosly check if it is possible to sudo without a password:

while : ; do
    echo | sudo -S echo "test" &>/dev/null && break
    sleep 10
done
sudo echo "We now have root access"

Prevention:

1 & 2. Use \/bin/sudo. The \ ignores aliases, and /bin/… ignores $PATH. Alternatively, add an alias such as: ssudo="\/bin/sudo", and always use ssudo instead of sudo. It seems unlikely that a virus would be clever enough to remap this alias.

3. Avoid typing your password when using X11. Instead, use a virtual console, or Weston.

5. Set timestamp_timeout=0 in /etc/sudoers.

The only way to completely eliminate the chance of the sudo password being sniffed, seems to be to avoid it altogether. Instead, login as root to a virtual console.

According to Alexander Peslyak: "the only safe use for su [and sudo] is to switch from a more privileged account to a less privileged one…"

On a side note, sudo does have some countermeasures:

• sudo reads from tty instead of stdin, so alias sudo='tee -a /tmp/sudo-password | sudo' breaks sudo (but does capture the password).

Solution 2:

There is no real protection.

Password protected access to sudo harks back to an era before complex shell environments with commands executed by shims. Once the password has been submitted, there's a window of opportunity in which a shim can execute commands via sudo, without any notification, and with full system control.

If I was intent on access, I'd create a useful shim for bash and zsh and fish, etc. I'd monitor the commands executed. Shortly after a sudo has returned with a status of zero, I'd start issuing "sudo chmod +s /bin/sh" or other nastinesses.

The moment that sudo has been given a satisfactory password, and you have shells that run commands to get a prompt, you're potentially in trouble. There is no protection, other than optimism.

Other answers have focused on protecting the password. As an aggressor, I wouldn't worry about that. I'd focus on the duration after the password has been given, when a password is not needed. That's the most risky time, when the attacker needs to do least to compromise the system completely.

Protecting from it? You'd have to protect your RC files. Inspect any shims or other commands used in command line prompts. Look for co-processes connected to the shell and tools used to maintain the shell environment. Main defences would be host intrusion tools, but that's after-the-fact. Preventing attacks? Only using simple shells without complex automated configuration and active prompts - that's the environment for which sudo was developed.

I used to play games with other devs (1980's) where we'd try to write stuff that would get the terminal that the other dev was using, to insert commands - this is essentially the same problem. And we've made it much easier to embed tools that would do command insertion with no visible trace. :)

Solution 3:

Not sure about any methods for unauthorized users to gain root privileges, but I know something you can do to make sudo a bit less dangerous, if you want to say that. sudo allows you to configure granular permissions, in order to define groups of users with specific privileges, and specific commands that certain users can run.

SUDO - GRANULAR CONTROL

• User Section

  This where you can setup groups for the users you will specify commands for. Lets setup an Operations group;

  User_Alias  OPS = bob, jdoe 
  

  This creates the OPS group and puts the users named bob and jdoe into the group

• Cmnd_Alias

  Here we specify specific command sets. You must specify the full path and any command options you want used. Lets setup the Operations group commands;

  Cmnd_Alias OPSCMD = /admin/bin/srvbkup, /admin/bin/test 
  

  This adds the three specified commands to the command group OPSCMD.

• User Privilege Specification

  This is where we will use the groups we have setup so far;

  OPS  ALL=(root)  OPSCMD 
  

  First thing we specify are the users, here we use the OPS group we setup. Then the ALL means that it applies to all servers, this is useful only if you or running sudo over multiple servers each using the same configuration file. Next we specify the user that the Operations group will run the specified commands as, in this case we want them to run as root. Lastly we specify the commands that we want the OPS group to be able to run, specifically we are using OPSCMD group we setup. If you did not want them to enter their password each time they used sudo, then the command specification would rather be NOPASSWD: OPSCMD.

Just harden your sudo policies as much as you don't trust your users :)