Security-Oriented C Tutorial 0x20 - Problems with popen and Shifty system

How's it goin'? In this tutorial, we will learn about the security issues of the popen and system functions. I've seen a few people attempting to run command line utilities or whatever it is they require with calls to these two functions but may not know the security implications which come along with it. I will show you using an example from the wargame IO Smash The Stack.

The Vulnerability

These functions invoke a call to the shell and run the command which they are given but the problem with this is the questionable integrity of the executed command or environment variable(s) which the command depends upon. If either of these were in some way altered maliciously, there could be havoc.

IO Smash the Stack

Some small details we need to know before we continue:

• The user is named levelX where X is the number corresponding to the level. For example we are on level 4 of this wargame and hence our user is level4
• The programs which we require to exploit is run under the user of the level above us. In this case, the programs are run under level5
• The password file is stored in the directory of the level above us, i.e. /home/levelX/.pass

Let's begin.

Exploitation Process

Back to IO Smash The Stack, the source code to the program is given to us.

We can see that this program makes a call to popen requesting the whoami utility. We can also see that this program is run under the permissions of the user level5 which means that the program, if we exploit it, has the permissions to access the password file, which is the entire point of this wargame.

Let's run it and see what happens.

So this program calls the whoami util and captures the output into the f file pointer. fgets is called to write it to the username buffer and printf prints out a welcome message with the buffer appended. How do we exploit this? Well, we'll need to know a little bit about the Linux environment. Running utilities on the command line makes use of the PATH environment table which searches for the binary to execute.

There are multiple directories in the variable each separated by a colon. The search for the executable must go in order from left to right where the most left is prioritized. What if we were to alter or change the whomi search to our own directory to run our own version of whoami? Let's try.

We know the password is located in /home/level5/.pass so let's echo it into a file called whoami in the /tmp directory.

Cool! Now let's go back into the directory of the program and edit the PATH environment table by prepending the directory of where our whoami file is located. We also need to set it for full permissions so that user level5 can run it. Aaand run the program.

And exploit is successful! The password is behind the censor bar, I promise. Don't believe me? Go through level 1 to 3 and then try it yourself!

Good luck!

For those who want to go to the next level of exploitation, try owning user level5 by spawning a shell!

Conclusion

If you require your code to be secure, it's highly recommended that you do NOT use either of these functions. As an alternative, the fork/exec/pipe can be used as a safer substitute. Sounds like too much work, you say? Well, there's always a price to pay for security.

dtm.

P.S. If you find that some malware is using these commands, maybe you can try to exploit the malware! Which begs the question: what happens when the hunter gets hunted?