在本次比赛中，我主要做了 Linux Kernel 方向的漏洞利用，也看了一些别的题，以下是我对题目的一些总结：

本次比赛我认为题目质量很高，都是较为新颖的题目形式/考点，或者偏realword一点的题目。

本题的文件系统不能直接调试，需要做一定修改之后才能正常启动。

（感谢 @Lime 当时跟我凌晨还在讨论怎么调试这个文件系统）

题目给出了一个 ext4 的文件系统的.img。

这种 rootfs.img 不能够直接使用 cpio 工具进行解压，而应该用mount+umount进行 unpack-->change-->pack。

具体如下：

在mount到 ./rootfs 之后，你可以进入 ./rootfs 对文件进行修改，而我们的修改可以同步到文件系统中。

修改结束后一定要执行：

Umount文件系统，然后再用qemu启动才可以正常调试。如果不进行umount，无法正常的启动内核。

本题给了一个裸的UAF，没有任何保护，利用非常简单，思路较为清晰。

思路：

我个人的 exp 以及题目的 .c 文件如下：

exp.c : https://paste.ubuntu.com/p/yfPFQh2Q7w/

ctf.c : https://paste.ubuntu.com/p/f8qjBzt3HM/

本题偏realword，主要考察了Linux内核eBPF虚拟机漏洞利用，当时做了半天没做出来，最后由 @2019 师傅出了这道题，我跟着师傅的思路再做复盘。

传送门：Google CTF 2021 eBPF

首先本题由于是需要基于qemu下进行爆破，所以我基于python编写了一个爆破脚本。

script

<u>Somthing useful in verifier.c's comments：</u>

eBPF 寄存器

* All registers are 64-bit.

* R0 - return register

* R1-R5 argument passing registers

* R6-R9 callee saved registers

* R10 - frame pointer read-only

At the start of BPF program the register R1 contains a pointer to bpf_context and has type PTR_TO_CTX.

在eBPF程序的一开始R1类型为 PTR_TO_CTX

eBPF寄存器类型

Most of the time the registers have SCALAR_VALUE type, which means the register has some value, but it's not a valid pointer.(like pointer plus pointer becomes SCALAR_VALUE type)

大多数时间是reg是标量类型而不是指针类型。

PTR_TO_MAP_VALUE means that this register is pointing to 'map element value'

and the range of [ptr, ptr + map's value_size) is accessible.

更多有用的comments的可以看：https://paste.ubuntu.com/p/dHpJr3vp46/

主要是在 struct bpf_reg_state eBPF寄存器结构体中 加了一个 bool auth_map

https://elixir.bootlin.com/linux/v5.12.2/source/include/linux/bpf_verifier.h#L161

在 adjust_ptr_min_max_vals 里打了patch

https://elixir.bootlin.com/linux/v5.12.2/source/kernel/bpf/verifier.c#L6131

被patch的函数主要用于处理：对于 指针 与 标量 的算术运算，并计算新的最大最小的var_off。

在 正常的 函数中不允许指针与标量做位运算：

这里会直接 return -EACCES;

并且，在 adjust_reg_min_max_vals 中还指出了：两个指针之间只能做减法运算。

主要是在eBPF寄存器中加了一个 auth_map 变量，在处理 adjust_ptr_min_max_vals 时：

case BPF_XOR:

对于XOR来说，假如我们是：

且 dst_reg 为 PTR_TO_MAP_VALUE 类型。

如果我们将 dst_reg 设置为一个地址，类型为 PTR_TO_MAP_VALUE。

经过测试，当这个值类型为PTR_TO_MAP_VALUE时，对这个指针类型的寄存器进行算术运算是有限制的（边界），eBPF-verifier会对其进行一些OOB的检测，以至于在指针类型的寄存器中我们无法构造指向任意地址的指针。

而如果我们通过XOR将其降级为一个标量类型，任何的运算都是直接的算术运算而不涉及到地址，进而不会触发verfier在jit过程中的检测。

这样我们就可以构造一个指向任意地址的寄存器（当然，此时寄存器被标识为标量类型而非指针类型）。

通过这个指向任意地址的寄存器，我们可以就可以在此基础上构造任意内存地址读写的原语。

首先我们要到达触发漏洞的地方，首先需要构造类型为 PTR_TO_MAP_VALUE 的寄存器。

我们主要关注以下这句话：

When the verifier sees a helper call return a reference type, it allocates a pointer id for the reference and stores it in the current function state.Similar to the way that PTR_TO_MAP_VALUE_OR_NULL is converted into PTR_TO_MAP_VALUE

.ret_type which is RET_PTR_TO_MAP_VALUE_OR_NULL, so it sets R0->type = PTR_TO_MAP_VALUE_OR_NULL which means bpf_map_lookup_elem() function returns ether pointer to map value or NULL.

When type PTR_TO_MAP_VALUE_OR_NULL <u>passes</u> through 'if (reg != 0) goto +off' insn, the register holding that pointer in the true branch <u>changes state to PTR_TO_MAP_VALUE</u> and the same register changes state to CONST_IMM in the false branch.

也就是说 bpf_map_lookup_elem() 会返回一个 PTR_TO_MAP_VALUE_OR_NULL 类型的 BPF_REG_0，如果这个BPF_REG_0 通过了 if 的 check，那么就会将其设置为 PTR_TO_MAP_VALUE 。

这样我们就有机会构造出多个类型为 PTR_TO_MAP_VALUE 的寄存器。

首先我们通过：bpf_create_map(BPF_MAP_TYPE_ARRAY,sizeof(int),0x100,0x1);

创建一个map。

此map中对应的key的大小为int，value的大小为 0x100，以及有且仅有一对 {key : value}

然后构造如下的 BPF insn：

使用 bpftools 调试效果如下：

可以看到，从0～7，与我们分析的差不多。

从8～14则是 BPF_FUNC_map_lookup_elem 具体做的操作。

comments中也给出了一个简短的介绍：

需要注意的是，在BPF helper func中，BPF程序需要返回的是value的指针，而用户态发起的bpf()系统调用需要返回的是value的值。

当程序成功执行之后，r0的类型为 PTR_TO_MAP_VALUE ，r0的值为成功查询到的对应的<u>地址</u>。

在这一部分，我们需要利用eBPF虚拟机的漏洞，利用他的指令编写可以任意内存读的原语。

此时我们已经有了对应类型的r0，我们通过mov指令，将对应的类型与值也赋值给r1、r2、r3寄存器。

然后使用patch后的XOR函数将他们的类型降级为标量，此时他们的值仍然是对应的地址。

接下来有一个技巧，我们可以通过看r2的值来确定我们要准备load addr的addr应该是多少

以下这两句将r2的值放到了map中，我们通过 bpf_lookup_elem(expmapfd,&key,&val) 可以查询到此时r2的值。（方便debug）

而实际情况中，在触发了两次漏洞后，没法对同一个再来XOR一次了，也就是说当我们将一个指针降级为标量后，无法再恢复成指针类型了。

于是可以采用：

恢复r1的指针类型。

然后将r1指向地址的值放入r2，最后将r2中保存的全局变量的值放入key=0即可。

收尾：

整个这一段如下：

在本部分，我们需要通过eBPF-asm构建任意内存写的原语。

本题中 modprobe_path 没有导出，在这种情况下，我们可以通过先构造一个 fake_elf，然后在 call_usermodehelper_setup 上打断点。

在call_usermodehelper_setup函数调用的过程中，其第一个参数$rdi 就是没导出的全局变量modprobe_path的地址。这样就可以知道不开kaslr下modprobe_path相对kernel base的偏移了。进而计算出真正的modprobe_path的地址。

最终构造出的任意内存写的原语如下：

在写的时候我发现了一个问题，对于modprobe_path这块内存，如果最终

将这一句的OR换成ADD，会触发到内核的内存保护。

但是如果用 OR ， 则可以正常写内存。暂不知道是为什么。

最后执行 我们 fake的文件即可。

linux ext4 img解包打包教程,解打包.img.ext4(转)

https://blog.csdn.net/pwl999/article/details/82884882

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！