Linux内核eBPF verifier天堑推算谬误缝隙分析与利用（CVE-2021-31440）
颁布功夫 2021-05-31缝隙布景
近日，，，，，，，ZDI官网披露一个Linux内核eBPF verifier天堑推算谬误缝隙，，，，，，，该缝隙源于eBPF验证器在Linux内核中没有正确推算64位转32位操作的寄放器天堑，，，，，，，导致本地攻击者能够利用此缺点进行内核信息泄露或特权提升，，，，，，，该缝隙编号为CVE-2021-31440。。。。。
影响领域与防护措施
（1）影响领域Linux-5.7 ~ Linux- 5.11.15Ubuntu 20.10
（2）防护措施
实时更新升级内核将kernel.unprivileged_bpf_disabled.sysctl设置为1，，，，，，，一时限度通常用户权限
缝隙道理与调试分析
（1）缝隙道理
该缝隙和CVE-2020-8835，，，，，，，CVE-2020-27194这两个缝隙的道理类似，，，，，，，均是在32位和64位之间进行转换操作时，，，，，，，谬误推算了寄放器的约束天堑，，，，，，，导致能够绕过验证器查抄实现越界读写。。。。。缺点代码呈此刻kernel/bpf/verifier.c的__reg_combine_64_into_32()函数中，，，，，，，该函数是在commit_id：3f50f132d840中引入的，，，，，，，该职能实现了用64位寄放器上的已知领域来揣度该寄放器低32位的领域，，，，，，，但是同样出现了类似的推算谬误，，，，，，，该函数实现如下：
行1316，，，，，，，若是smin_value和smax_value都在带符号的32位整数领域内，，，，，，，则将相应地更新32位的带符号领域大�。。。。。�，，，，，，对于有符号领域来说，，，，，，，这种操作是正确的。。。。。接着看，，，，，，，在无符号领域的相应逻辑中，，，，，，，对umin_value和umax_value别离在行1320和行1322进行了查抄。。。。。这里逻辑不正确，，，，，，，例如设置dreg->umin_value=1，，，，，，，dreg->umax_value=1<<32，，，，，，，即0x100000000，，，，，，，当进行如上操作后，，，，，，，reg->u32_min_value设置为1，，，，，，，这个是正确的，，，，，，，但是reg->u32_max_value却造成了0，，，，，，，高位被截断。。。。。这时reg寄放器的低32位领域已经混乱。。。。。对于验证器来说是混乱的，，，，，，，但是运行态时，，，，，，，reg的领域是正常的。。。。。其实对于有符号天堑的情况，，，，，，，已经进行了批改。。。。。补丁commit为：b02709587ea3，，，，，，，关键补丁代码如下所示：
而未对无符号天堑的情况进行解决。。。。。该缝隙补丁中，，，，，，，批改为同时对umin_value和umax_value进行了判断，，，，，，，如下所示：
（2）调试分析
首先将BPF_REG_7寄放器设置为1<<32，，，，，，，即0x10000000，，，，，，，并通过两个陆续的NEG指令使验证器无法跟踪寄放器的领域，，，，，，，同时能够保障寄放器的值在运行时不变。。。。。浚浚�？？Ｄ芄煌ü缦翨PF指令实现：
执行到LSH指令时，，，，，，，如下所示：
此时BPF_REG_7寄放器的状态如下所示：
执行完LSH后，，，，，，，此时BPF_REG_7寄放器的状态如下图所示：
但是此时umin_value也是0x100000000，，，，，，，还需将umin_value设置成0x1，，，，，，，能够通过如下eBPF指令实现：
断点射中后，，，，，，，挪用栈如下所示：
对BPF_JGE和BPF_JGT指令进行处置，，，，，，，这里不是32位指令操作，，，，，，，执行如下代码：
若是R7 >= 0x1，，，，，，，则验证器正确分支上，，，，，，，true_reg->umin_value设置为true_reg->umin_value和true_umin之间的最大值，，，，，，，这里设置成true_umin，，，，，，，为0x1。。。。。而后挪用__reg_combine_64_into_32()函数更新一下true_reg的领域。。。。。如下代码所示：
进入该函数后，，，，，，，首先判断有符号领域的情况，，，，，，，如下代码所示：
这里同时判断有符号大幼值，，，，，，，了局不为真，，，，，，，不进入if语句，，，，，，，因而不会批改32位的有符号大幼值，，，，，，，打印true_reg的状态如下所示：
而后起头判断无符号最幼值的情况，，，，，，，了局为真，，，，，，，而后批改32位无符号最幼值，，，，，，，如下代码：
由于这里分隔进行判断，，，，，，，能够成功设置reg->u32_min_value为0x1。。。。。接下来判断无符号最大值，，，，，，，reg->umax_value为0xffffffffffffffff，，，，，，，大于0xffffffff。。。。。因而前提不为真，，，，，，，不批改reg->u32_max_value。。。。。最后true_reg的状态如下所示：
将寄放器的umin_value和u32_min_value都设置为0x1。。。。。接下来通过如下eBPF指令组合将u32_max_value也设置为0x1。。。。。如下所示：
该指令为W7<=0x1，，，，，，，W7为32位寄放器。。。。。射中断点后，，，，，，，挪用栈如下所示：
若是W7<=0x1，，，，，，，接下来设置正确分支下的true_reg->u32_max_value，，，，，，，如下图所示：
行7200，，，，，，，将true_reg->u32_max_value设置为true_umax，，，，，，，为0x1。。。。。此时true_reg的状态如下所示：
而后挪用__reg_combine_32_into_64()函数更新true_reg的领域，，，，，，，如下所示：
更新领域后，，，，，，，最后true_reg的状态如下所示：
此时在验证器的视角中，，，，，，，R7寄放器的32位领域是固定值，，，，，，，为常数0x1。。。。。接下来通过如下eBPF组合将R7变换成0，，，，，，，如下所示：
首先通过MOV32将R7的64位领域也设置常数0x1。。。。。执行完MOV32指令后，，，，，，，在验证器的视角下R7寄放器的状态如下所示：
而在运行时，，，，，，，R7的值为1<<32，，，，，，，即0x100000000，，，，，，，低32为0，，，，，，，即R7的32位领域为常数0，，，，，，，而后通过MUL和ADD两次操作，，，，，，，将R7寄放器的状态转换成在验证器的视角下为0x0，，，，，，，在运行时为0x1，，，，，，，最终便能够实现越界读写。。。。。
缝隙复现
在Linux-5.11.0内核版本的特定测试环境中进行缝隙利用测试，，，，，，，成功提权。。。。。
参考链接
1.https://www.zerodayinitiative.com/blog/2021/5/26/cve-2021-31440-an-incorrect-bounds-calculation-in-the-linux-kernel-ebpf-verifier
2.https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10bf4e83167cc68595b85fd73bb91e8f2c086e36
3.https://github.com/torvalds/linux/commit/b02709587ea3d699a608568ee8157d8db4fd8cae
4.https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31440
8827太阳集团积极防御尝试室（ADLab）
ADLab成立于1999年，，，，，，，是中国安全行业最早成立的攻防技术钻研尝试室之一，，，，，，，微软MAPP打算主题成员，，，，，，，“黑雀攻击”概想首推者。。。。。截止目前，，，，，，，ADLab已通过CVE累计颁布安全缝隙近1100个，，，，，，，通过 CNVD/CNNVD累计颁布安全缝隙1000余个，，，，，，，持续维持国际网络安全领域一流水准。。。。。尝试室钻研方向涵盖操作系统与利用系统安全钻延注智能终端安全钻延注物联网智能设备安全钻延注Web安全钻延注工控系统安全钻延注云安全钻研。。。。。钻研成就利用于产品主题技术钻延注国度沉点科技项目攻关、专业安全服务等。。。。。
京公网安备11010802024551号