I recently posted a blog that details apotential attack malware can use to bypass Vista's User Access Control(UAC) protection. What the attack really comes down to, however, isthat if you run any untrusted code under a user account, that useraccount can no longer be trusted. Any shortcuts or programs in thataccount 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 artifactof the entire concept of user-separation. This time, I'm going todetail a similar attack against UNIX and Linux operating systems.
"Sudo" (super user do) is a command that can be used on Unix-basedoperating systems to allow a user to run certain programs with thehighest possible privilege (root). Sudo is similar to UAC in that itallows users to easily run programs with elevated privileges.
If a user runs a malicious program with a regular account, theprogram cannot install in a system-wide directory. On a typicalUNIX-based operating system, user-level programs can write to theuser's home folder, the temporary files directory, and a couple othersafe places. A malicious program run this way cannot affect other usersor the system as a whole.
However, if sudo is used to run this malicious program, the programcan make system-wide changes because it has root access. If a user canbe tricked into running a malicious program, the system can easilybecome fully compromised.
All that the malicious program has to do is copy itself to adirectory so that when a user runs a system program, the maliciousprogram runs instead. Although sudo takes steps to prevent this type ofbehavior, unfortunately, it's not enough, and can never be enough,because after a user runs a malicious program, anything they do iscompromised, including attempts to switch users and enter passwords.
The main protection offered by sudo is the assurance that thecurrent directory is the last place searched for commands. So if amalicious 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 takeadvantage of a common mistake: spelling errors. Even though "sudomount" will never check the current directory, "sudo moutn" will, and Ican't even count the number of times I've typed that. A piece ofmalware 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 Icommonly use are "ifcofnig," "tcpdmup," and, for Windows users,"ipconfig" or "tracert."
Another fairly easy way to get around sudo's protection is to changethe user's path to include a directory. For example, sudo's protectioncan be circumvented by adding "/tmp" to a user's path and creatingprograms named "mount," "ifconfig," etc. in the /tmp folder. Here is aquick 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 removesthe waiting period for the user to restart bash. However, even if bashisn't restarted, the user will almost certainly open a new terminalsooner or later, at which point "/tmp" will be at the start of theirpath 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. Whynot? They can't, for the same reason that UAC won't be fixed: as soonas untrusted code is run on a user account, nothing on that useraccount can be trusted anymore, be it variables, files, or programs.