CVE-2023-4208复现笔记

发布于2024年9月8日2025年7月19日作者:cve-20

CVE-2023-4208复现笔记

mb_btcapvow 看雪学苑 2024-09-07 17:59

commit：2c85ebc57b3e1817b6ce1a6b703928e113a90442

内核源码下载：

编辑 .config:

遇到问题：

objtool: Don’t fail on missing symbol table · Pull Request !141 · openEuler/kernel（https://gitee.com/openeuler/kernel/pulls/141/files）

◆Kernel configuration: CONFIG_NET_SCHED=y, CONFIG_NET_CLS_U32=y

所以总的config就是：

defconfig+menuconfig

在复现本CVE时，笔者已经有了CVE-2023-4207的复现经历，所以这里参照与之相同的思路进行复现，不过相关细节可能不再赘述，有不清楚的地方可以参照笔者的这一篇文章：[
原创]CVE-2023-4207复现笔记（https://bbs.kanxue.com/thread-283073.htm）

以下是一些触发漏洞的命令行：

相关源码路径如下：

在添加filter和替换filter的时候都会调用到这个函数；

这里的n应该就是旧的filter：

这里通过u32_init_knote分配新的过滤器：

可以看到在该函数中直接将旧的过滤器的res分配给新的过滤器：

然后tcf_unbind_filter旧的过滤器：

具体函数如下：

继续跟进到__tcf_unbind_filter:

这里调用了函数指针，通过调试后可以得知是这个函数（其实用的是drr，基本就是这个函数）：

下面看该函数的具体定义：

在这里将drr_class的filter_cnt减一；然而实际上，我们的class只是换了一个filter而已，其引用数不应该被减少；

剩下的就和CVE-2023-4207一样了，我们删除drr_class的时候会调用drr_delete_class函数：

如果引用计数<=0，就可以调用到drr_destroy_class：

这样就错误地释放了对应的qdisc和drr_class；

下面还是贴一张笔者分析的图：

主要是在drr_destroy_class下断点，然后查看cl，在后续喷射完pg_vec（当然也可以使用其他结构体）之后，可依据需使用该命令查看是否覆盖成功：

后边的攻击思路和CVE-2023-4207就一样了，提前喷射eBPF，是的在内核加载模块地址内部署好我们的代码片段，然后构造uaf，之后使用pg_vec喷射出来已经释放但是仍然被使用的drr_class，此时它的偏移0x60处的qdisc成员被填入了pg_vec申请的虚拟地址，虽然我们不知道这个地址，然后通过mmap可以映射这个地址，我们就有了写这个地址的权限，写其前8个字节为我们的目标地址，也就是我们喷射的eBPF地址，即可劫持控制流；然后实现地址泄露+覆盖core_pattern，最后在另一个进程触发crash，使得root1得到执行，提权成功！

poc.c:

pg_vec.h:

参考

https://github.com/google/security-research/blob/499284a767851f383681ea68e485a0620ccabce2/pocs/linux/kernelctf/CVE-2023-4208_lts_cos_mitigation/docs/exploit.md

objtool: Don’t fail on missing symbol table · Pull Request !141 · openEuler/kernel

（https://gitee.com/openeuler/kernel/pulls/141/files）