The Ultimate Aim of Kernel Exploitation - Process Credentials

Overview

Userspace exploitation often has the end goal of code execution. In the case of kernel exploitation, we already have code execution; our aim is to escalate privileges, so that when we spawn a shell (or do anything else) using execve("/bin/sh", NULL, NULL) we are dropped as root.

To understand this, we have a talk a little about how privileges and credentials work in Linux.

The cred struct

The contains all the permissions a task holds. The ones that we care about are typically these:

These fields are all unsigned int fields, and they represent what you would expect - the UID, GID, and a few other less common IDs for other operations (such as the FSUID, which is checked when accessing a file on the file system). As you can expect, overwriting one or more of these fields is likely a pretty desirable goal.

task_struct

The kernel needs to store information about each running task, and to do this it uses the structure. Each kernel task has its own instance.

The task_struct instances are stored in a linked list, with a global kernel variable init_task pointing to the first one. Each task_struct then points to the next.

Along with linking data, the task_struct also (more importantly) stores real_cred and cred, which are both pointers to a cred struct. The difference between the two is explained :

In effect, real_cred is the initial credential of the process, and is used by processes acting on the process. cred is the current credential, used to define what the process is allowed to do. We have to keep track of both as some processes care about the initial cred and some about the updated.

An example of caring about the real_cred instead of cred is in of /proc/$PID/status, which displays the real_cred as the owner of a process, even if privileges are elevated (note that is a macro to grab real_cred, confusingly). Conversely, setuid executables will modify cred and not real_cred.

So, which set of credentials do we want to target with an arbitrary write? It will depend on what set is relevant for the purpose, but since you usually want to do be creating new processes (through system or execve), the cred is used. In some cases, real_cred will work too, because it seems as if the pointers (though note that this excerpt is not from process creation but , which is , so it could differ for new process creation).

prepare_kernel_cred() and commit_creds()

As an alternative to overwriting cred structs in the unpredictable kernel heap, we can call prepare_kernel_cred() to generate a new valid cred struct and commit_creds() to overwrite the real_cred and cred of the current task_struct.

prepare_kernel_cred()

The function can be found , but there's not much to say - it creates a new cred struct called new then . It returns new.

If NULL is passed as the argument, it will , which . This is very important, as it means that calling prepare_kernel_cred(0) results in a new set of root creds!

commit_creds()

This function is found , but ultimately it will update task->real_cred and task->cred to the new credentials:

Resources and References