I recently posted a blog that details a potential attack malware can use to bypass Vista's User Access Control (UAC) protection. What the attack really comes down to, however, is that if you run any untrusted code under a user account, that user account can no longer be trusted. Any shortcuts or programs in that account may be infected, waiting for an opportunity to seize control. The problem is, this isn't a mistake on Vista's part; it's an artifact of the entire concept of user-separation. This time, I'm going to detail a similar attack against UNIX and Linux operating systems.
"Sudo" (super user do) is a command that can be used on Unix-based operating systems to allow a user to run certain programs with the highest possible privilege (root). Sudo is similar to UAC in that it allows users to easily run programs with elevated privileges.
If a user runs a malicious program with a regular account, the program cannot install in a system-wide directory. On a typical UNIX-based operating system, user-level programs can write to the user's home folder, the temporary files directory, and a couple other safe places. A malicious program run this way cannot affect other users or the system as a whole.
However, if sudo is used to run this malicious program, the program can make system-wide changes because it has root access. If a user can be tricked into running a malicious program, the system can easily become fully compromised.
All that the malicious program has to do is copy itself to a directory so that when a user runs a system program, the malicious program runs instead. Although sudo takes steps to prevent this type of behavior, unfortunately, it's not enough, and can never be enough, because after a user runs a malicious program, anything they do is compromised, including attempts to switch users and enter passwords.
The main protection offered by sudo is the assurance that the current directory is the last place searched for commands. So if a malicious program named "mount" is placed in the user's home directory, the command "sudo mount" will still run the real mount command (/sbin/mount, likely).
The simplest way to get around sudo's protection is to take advantage of a common mistake: spelling errors. Even though "sudo mount" will never check the current directory, "sudo moutn" will, and I can't even count the number of times I've typed that. A piece of malware can name itself "moutn" and hide in the user's home directory, hoping to take advantage of a spelling mistake before being discovered. The number of possible names is endless, but some others that I commonly use are "ifcofnig," "tcpdmup," and, for Windows users, "ipconfig" or "tracert."
Another fairly easy way to get around sudo's protection is to change the user's path to include a directory. For example, sudo's protection can be circumvented by adding "/tmp" to a user's path and creating programs named "mount," "ifconfig," etc. in the /tmp folder. Here is a quick example I wrote:
#!/bin/sh
echo "echo 'exploited!'; whoami" > /tmp/mount
echo "echo 'exploited!'; whoami" > /tmp/ifconfig
chmod +x /tmp/mount
chmod +x /tmp/ifconfig
echo export PATH=/tmp:$PATH>>.bash_profile
/bin/bash -l
Running a new bash process is probably unnecessary, but that removes the waiting period for the user to restart bash. However, even if bash isn't restarted, the user will almost certainly open a new terminal sooner or later, at which point "/tmp" will be at the start of their path and the malicious code will run as root.
Here's an example of that script in action:
rbowes@linux:~$ ./malicious.sh
rbowes@linux:~$ sudo mount /dev/cdrom
Password:
exploited!
root
Note how "./malicious.sh" isn't run with sudo. It doesn't have to be, since the mount command will be.
So the question becomes, will the makers of sudo fix this? No. Why not? They can't, for the same reason that UAC won't be fixed: as soon as untrusted code is run on a user account, nothing on that user account can be trusted anymore, be it variables, files, or programs.
Total Members: 14197
