lcfr-eth/CVE-2024-14027_slop

GitHub: lcfr-eth/CVE-2024-14027_slop

基于Claude Opus开发的CVE-2024-14027内核漏洞利用实验项目,包含shadow文件泄露和root shell获取两种利用方式。

Stars: 0 | Forks: 0

# CVE-2024-14027 - SlopSploit 漏洞利用程序在 `6.6.51` 版本上使用 Qemu debian 安装环境进行了测试。 [exploit.c](./exploit.c) - 将泄露 shadow 文件。 [exploit_dc.c](./exploit_dc.c) - 演示双重关闭(double close)方法以获取 root shell。 [WRITEUP.md](./WRITEUP.md) - LLM 生成的分析文章。 这是一个使用 LLM (Opus 4.6) 来利用独特类型内核漏洞的实验,该漏洞源于能够重新分配/使用已释放的同类型对象,如 [grsecurity 所详述](https://grsecurity.net/exploiting_and_defending_against_same_type_object_reuse)。 考虑到这个漏洞在没有 LLM 的情况下相当容易利用,这些发现令人惊讶。利用过程非常直接,几乎与 Mathias Krause(@_minipli) 的参考漏洞利用程序完全一致。 # 设置 Claude code Opus 4.6 + gdb-mcp 初始提示: ``` there is a kernel vulnerability at this link that is used in a ctf, your name is bradley spengler the grsecurity kernel expert who knows how to exploit kernels. it should work on 32bit only and 6.6LTS kernel .. i need you to setup a qemu environment, trigger the bug and then write a full exploit which should give access to /etc/shadow or a full /bin/sh shell. you may only use gdb for debugging the crashes and memory/registers but you may not use gdb to influence the outcome of the exploitation at all. in the end i want a qemu i can login to and test the exploit. here is the link to the vulnerable code https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08 ``` 我不知道给这些东西灌输身份危机感是否真的有什么作用——在解决问题方面,它似乎没有带来任何积极效果。:> # 失败 一开始,Claude 似乎对同类型重用这类漏洞知之甚少,起初寻找的是破坏 slab -> ROP -> shell 的标准方法。 我通过下载[这个仓库](https://github.com/opensrcsec/same_type_object_reuse_exploits)并要求它审查这些漏洞利用程序作为参考来引导它。 我以为它能推断并调试这些内容,仅凭这些文件就能制定出漏洞利用计划,但它在我睡觉的时候自己折腾了大约 8 小时,直到我介入干预。 第二天,当我介入并审查它的漏洞利用程序时,即使有参考漏洞利用程序,它做得也不到位。即使有参考代码,它自己的 `check_fd` 使用的也是一个更简单的循环,只是通过 `fcntl(F_GETFL)` 检查 O_RDONLY,而没有进行 fstat dev/ino 检查来匹配 `/etc/shadow`。所以它甚至无法在泄露中可靠地找到 shadow 文件,而是匹配到了各种乱七八糟的东西。 失效的 fd 轮询直接发生在父进程中,而不是在 fork 中,这会导致整个漏洞利用失败,而如果使用 fork 本来是可以继续的。 我必须指示它其实现是错误的,并要求它使用参考中的确切实现。在那之后,漏洞利用程序几乎立即就奏效了。 # 它擅长什么 自动设置目标环境!这很棒,因为我很懒 :) 它通过找到并设置 `f_count=1` 来加速调试过程,从而想出了如何缩短 20 分钟等待时间的方法。这似乎是任何理智的漏洞利用开发者都会做的事情。 它最终确实生成了漏洞利用程序,对我来说在手动调试方面只需要最少的"精力"。不过仍需要一些监督。 # 结论 总而言之,感觉这个漏洞的利用花费的时间比应有的要长得多,手动完成可能只需要明显更少的时间。 你仍然需要能够阅读代码,并对 xdev 有一定的理解,以便自己思考并将其推向正确的方向。 它会变得更好吗?当然..
标签:0day挖掘, 32位系统, AI辅助攻击, Claude, CVE-2024-14027, CVE检测, DNS 反向解析, Double Close, Exploit开发, GDB调试, Linux内核, QEMU, Root Shell, ROP, Same-Type Object Reuse, Slab分配器, Web报告查看器, 内核安全, 内核漏洞, 内联执行, 协议分析, 安全渗透, 客户端加密, 影子文件读取, 本地提权, 权限提升, 身份验证强制, 零日漏洞