security - why does GDB lower its privilege during debugging?

Question

GDB lowers its privileges during debugging - for instance, SETUID root programs won't run with root privilege.

I do not see why GDB should lower its privilege, since GDB is utilized on administrator-access regarding the binary. Is there any explicit reason why it lowers its privilege?

标签： securitydebugginggdbprivileges

Answer 1

I don't understand your second paragraph at all, but lets work through an example. I'm debugging a test program borrowed from here:

#define _POSIX_C_SOURCE 200112L // Needed with glibc (e.g., linux).
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

void report (uid_t real) {
    printf (
        "Real UID: %d Effective UID: %d\n",
        real,
        geteuid()
    );
}

int main (void) {
    uid_t real = getuid();
    report(real);
    seteuid(real);
    report(real);
    return 0;
}

Then compile and setuid with:

gcc -g3 -O0 -o testuid testuid.c
sudo chown root testuid
sudo chmod u+s testuid

Now, when I run this without GDB:

$ ./testuid
Real UID: 1000 Effective UID: 0
Real UID: 1000 Effective UID: 1000

And now with GDB:

$ gdb -quiet -batch -ex run ./testuid
Real UID: 1000 Effective UID: 1000
Real UID: 1000 Effective UID: 1000
[Inferior 1 (process 3134807) exited normally]

I think you're asking why the setuid doesn't work when run under GDB.

It's not that GDB is choosing to drop privilege, but rather the kernel that prevents the test program acquiring privilege when being run under the debugger, when the debugger has a lower privilege level.

Imagine for a moment if this wasn't the case, I, a non privileged user can just debug a setuid binary and get root privilege. At this point I could use the debugger to inject any code I like and execute that code with root permissions.

The only way to debug a setuid binary with the setuid privilege level is to "show" the kernel that you already have access to that privilege level, so, for example:

$ sudo  gdb -quiet -batch -ex run ./testuid
Real UID: 0 Effective UID: 0
Real UID: 0 Effective UID: 0
[Inferior 1 (process 3138369) exited normally]

Of course, it's no longer the setuid bit that is giving the test program root, we're starting the test program as root, but as far as I know that's going to be your only option.