Ah, hacking! Well, let's at least attempt to.

We know that EUID 0 is a special value—it means we have root privilege. Think about it—we have a setuid(2) system call. So, even if we're unprivileged, why not just do a quick

setuid(0); become privileged, and hack away as root!

Hmm, Linux wouldn't be a very powerful and popular OS if the above hack were to actually work. It won't work, folks: the above system call invocation would fail returning -1; errno would be set to EPERM and the error message (from perror(3) or strerror(3)) would be this: Operation not permitted.

Why is this? There's a simple rule within the kernel: an unprivileged process can set its effective IDs to its real IDs—no other value is allowed. In other words, an unprivileged process can set  the following:

• Its EUID to its RUID
• Its EGID to its RGID

That's it.

Of course, a (root) privileged process can set its four credentials to any value it chooses. There is no surprise there—this is part and parcel of the power of being root.

Let's be empirical and try out what we just talked about:

$ cat rootsh_hack2.c
[...]
int main(int argc, char **argv)
{
    /* Become root */
    if (setuid(0) == -1)
        WARN("setuid(0) failed!
");

    /* Now just spawn a shell;
     * <i>Evil Laugh</i>, we're now root!
     */
    system("/bin/bash");
    exit (EXIT_SUCCESS);
}

Build and run it. This screenshot shows us a virtual machine seawolf, along with an ssh-connected Terminal window in the lower right (where we're logged in as the user seawolf); see the rootsh_hack2 program running there:

Studying the output of the ssh terminal window in the preceding screenshot, we can see the following:

• The original bash process (the shell) has the PID 6012.
• The id command shows that we're running as (a real) UID = 1000 (which is the seawolf user).
• We run rootsh_hack2; clearly, the setuid(0) fails; the error message is displayed: operation not permitted.
• Nevertheless, it's just a warning message; execution continues, and the process spawns another bash process, in effect, another shell.
• Its PID is 6726 (proving it's unique from the original shell.)
• The id(1) is still 1000, proving we have not really achieved anything significant.
• We exit and are back to our original shell.

But what if we (or worse, a hacker) could trick this process into running as root!? How? By making it a setuid-root executable of course; then we're in trouble:

$ ls -l rootsh_hack2
-rwxrwxr-x 1 seawolf seawolf 8864 Feb 19 18:03 rootsh_hack2
$ sudo chown root rootsh_hack2
[sudo] password for seawolf: 
$ sudo chmod u+s rootsh_hack2
$ ls -l rootsh_hack2
-rwsrwxr-x 1 root seawolf 8864 Feb 19 18:03 rootsh_hack2
$ ./rootsh_hack2
root@seawolf-mindev:~/book_src/ch7# id -u
0
root@seawolf-mindev:~/book_src/ch7# ps
  PID TTY          TIME CMD
 7049 pts/0    00:00:00 rootsh_hack2
 7050 pts/0    00:00:00 sh
 7051 pts/0    00:00:00 bash
 7080 pts/0    00:00:00 ps
root@seawolf-mindev:~/book_src/ch7# exit
exit
$ 

So, we just simulate being tricked: here we use sudo(8); we enter the password and thus change the binary executable to a setuid-root, a truly dangerous, one. It runs, and it spawns what now turns out to be a root shell (notice, the id(1) command proves this fact); we do a ps and then exit.

It also dawns on us that our previous hacking attempt failed to deliver—the system(3) API refused to elevate privileges when a shell was the parameter to run—which is great security-wise. But, this hacking attempt (#2) proves that you can easily subvert that: just issue a call to setuid(0) prior to invoking system (/bin/bash), and it succeeds in delivering a root shell—of course, if and only if the process runs as root in the first place: either via the setuid-root approach or by just using sudo(8).