Let's check /home/flag01:
level01@nebula:~$ ls -l /home/flag01 total 8 -rwsr-x--- 1 flag01 level01 7322 2011-11-20 21:22 flag01SUID binary, that must be it. Analyzing the source code, we see that the program is very straightforward. It Sets the Real, Effective and Saved UIDs the same as the Effective UID (you can look up what these do). This is so that the SUID process is now effectively running as if called by the owner (flag01).
After this, the program executes "/usr/bin/env echo and now what?". That looks kind of normal... So where's the vulnerability?
Well, as it turns out, when you invoke a program without specifying it's absolute path, linux will look for it in the $PATH environment variable. But $PATH is controlled by us, so what stops us from specifying our own path with a malicious 'echo' program in it? Nothing. Let's go ahead and do just that. Our malicious 'echo' will be simple: it will just launch a shell. Since it's called by user flag01, we will have the same privileges.
level01@nebula:~$ echo '/bin/sh' > /tmp/echo level01@nebula:~$ chmod +x /tmp/echo level01@nebula:~$ export PATH=/tmp:$PATH level01@nebula:~$ /home/flag01/flag01 sh-4.2$ id uid=998(flag01) gid=1002(level01) groups=998(flag01),1002(level01) sh-4.2$ getflag You have successfully executed getflag on a target accountYay, another flag for us! :)
If you were wondering, /usr/bin/env is specified so that the shell treats echo as an actual program, not as the built-in command. If there were no built-in command, you could omit /usr/bin/env