How the shell finds commands

PATH is a search list

When you type ls, the shell does not know where ls lives. It searches a list of directories held in the PATH variable, left to right, and runs the first match it finds:

echo $PATH
which ls

In the terminal

student@vulntech:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
student@vulntech:~$ which ls
/usr/bin/ls

This matters for privilege escalation when a root process runs a command by its bare name (backup-logs) instead of its full path (/usr/bin/backup-logs). If you can get your own file found first, root runs your file.

A root job that trusts PATH

Look at the maintenance job and the script it runs:

cat /etc/cron.d/maint
cat /opt/maint/collect.sh

In the terminal

student@vulntech:~$ cat /etc/cron.d/maint
# admin maintenance job
PATH=/opt/maint/bin:/usr/bin:/bin
* * * * * root /opt/maint/collect.sh >/dev/null 2>&1
student@vulntech:~$ cat /opt/maint/collect.sh
#!/bin/sh
# Roll up the day log files. Calls backup-logs from PATH.
cd /opt/maint/data
backup-logs

Two things stand out. The cron line sets PATH=/opt/maint/bin:/usr/bin:/bin — so /opt/maint/bin is searched first. And collect.sh calls backup-logs by bare name. Where can you write?

ls -ld /opt/maint/bin

In the terminal

student@vulntech:~$ ls -ld /opt/maint/bin
drwxrwxrwx 2 root root 0 Oct 19 06:12 /opt/maint/bin

/opt/maint/bin is world-writable, and it is first on root's PATH. If you drop a file called backup-logs there, root's job will find and run yours.