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
OG东方厅积极防御尝试室（ADLab）
ADLab成立于1999年，，，是中国安全行业最早成立的攻防技术钻研尝试室之一，，，微软MAPP打算主题成员，，，“黑雀攻击”概念首推者。。截止目前，，，ADLab已通过CVE累计颁布安全缝隙近1100个，，，通过 CNVD/CNNVD累计颁布安全缝隙1000余个，，，持续维持国际网络安全领域一流水准。。尝试室钻研方向涵盖操作系统与利用系统安全钻研、智能终端安全钻研、物联网智能设备安全钻研、Web安全钻研、工控系统安全钻研、云安全钻研。。钻研成就利用于产品主题技术钻研、国度重点科技项目攻关、专业安全服务等。。
京公网安备11010802024551号