Back on exploit

It's been over two years since I last got my chance to play around with exploits and security; and I probably won't touch it till a friend asks me for help on a wargame on io.smashthestack.org. 

The level is simple enough, yet it took me over an hour to get the shell. Rusty! But that's not the point of the level. Here is a rough overview of level9 challenge:

• main() calls do_sth_nasty() with argv
• do_sth_nasty() use strncpy and strncat to a local buffer for agrv[1] and argv[2].
• There is no check on argc, argv[1], and argv[2], blah blah

Now forcing level8 binary to spawn a shell is way simple. It seems the host does not configure ASLR. Even so, we can easily local attack and put the shellcode on env[]. My friend did the same, and easy enough he got the shell. But, he can't seem to read the password, which stays in a file under /home/level9. level8 has been suid, and owned by user level9...why can't he just spawn the shell and read the password...? 

The problem is, most linux and many other major *nix OS do not support switching effective user id based on suid bit on executable file. If the user is already root, she can easily drop down to a normal user. But if real uid is not root, then linux execve do not allow effective UID of the new process to be anything different.  One more important thing, bash shell also try to detect if real UID is different from effective UID, and will switch back to RUID unless RUID is 0.

So....what can we do? There are a few potential solutions for this level, all of which I did not have a chance to test:

1. Forget the shell. We know where the password file is already, instead of spawning the shell, just open(), read() and close() the file directly already.
2. Set the Real, Effective and Saved UID into the new user level9 as soon as the shellcode execute. Then, we can spawn a shell, and bash will happily stay as level9.

Either solution require us to write our own shellcode (meh, you should anyways. Never trust any bits/bytes downloaded from the net); and, the size of the shell code may increase pass the 32bytes allocated (kind of, not counting alignment and compiler changes).

As you can see, the point of the level is not about spawning a shell; but trying to overcome other security measure the environment happen to have. Most people don't even have a solid understanding of UID, EUID, RUID and SUID, let alone how the OS or the shell handle the cases. Moreover, security measures change rapidly, as attack vectors and technology improves themselves. If you feel too comfortable with yourself, you've fallen behind.