FreeBSoD：利用语言模型发现和利用内核漏洞（上）

# FreeBSoD：利用语言模型发现并利用内核漏洞（上篇） 来源：https://www.praetorian.com/blog/ai-vulnerability-research-freebsd-kernel ## 概述 今年早些时候，Praetorian 的一个团队正在构建Constantine (https://www.praetorian.com/blog/the-attack-helix-praetorian-guards-ai-architecture-for-offensive-security/)，这是我们自动化的 0 day 发现引擎。我想找一些值得融入其中的技术，于是开始用 Claude Code 对 FreeBSD 内核进行一些探索，运行在当时最新的 Opus 4.6 模型上。几天的努力发现了一些真实漏洞，又过了一个周末，我们制作出了两个能够从 FreeBSD 监狱（jail）中逃逸的有效利用程序。 本文是系列文章的第一部分。在第一部分中，我将重点介绍发现这些漏洞所用的方法；第二部分将重点介绍我们利用和开发这些漏洞所用的方法。自从我向 FreeBSD 安全团队报告了大约八个独立漏洞以来，已经过去几个月了。现实情况是，这是一个志愿者团队，面对众多安全研究人员利用大型语言模型在 FreeBSD 中发现的大量漏洞，他们很可能已经不堪重负。 因此，我们只能公开讨论其中一个已报告的漏洞——CVE-2026-3038 (https://www.cve.org/CVERecord?id=CVE-2026-3038)，这是一个相当直接的栈溢出漏洞，已于 2026 年 2 月 24 日在FreeBSD-SA-26:05.route (https://www.freebsd.org/security/advisories/FreeBSD-SA-26:05.route.asc)中修复。其他问题也已披露，但仍在等待修复和补丁。因此，本文将主要聚焦于通过将语言模型整合到漏洞发现工作流中所采用的方法论。 ## 为什么选择 FreeBSD？ FreeBSD 是一个相当小众的操作系统，你没听说过它也很正常。它默默地支撑着大量关键基础设施，通常作为隐藏在某种其他组件内部的一部分。Juniper 的 Junos（运行在全球很大一部分路由器、交换机和防火墙上）就是基于 FreeBSD 构建的。Netflix 的大部分互联网视频流量都是通过位于 ISP 网络内部的基于 FreeBSD 的设备 (https://openconnect.netflix.com/en/appliances/) 传输的。Sony 的 PlayStation 基于 FreeBSD，而 Nintendo Switch 则借用了 FreeBSD 代码中的网络栈（得益于宽松的 BSD 许可证）。 FreeBSD 是一个适合副项目的实用选择。它看起来是一个通过几天的实验就有可能发现真实漏洞的目标，同时其部署范围又足够广泛，使得发现漏洞变得有趣。 此外，它也不是一个“玩具级”目标。基础缓解措施一应俱全：SMEP、SMAP、KASLR 和栈金丝雀都已启用，因此利用也并非易事。FreeBSD 拥有与大多数现代操作系统和软件相同的漏洞利用缓解措施，但不像 OpenBSD 那样经过严格加固。这种组合使得 FreeBSD 成为了解当时像 Claude Opus 4.6 这样的前沿模型在漏洞利用开发能力方面的一个有用基准。 ## 难点所在 在将 Claude Code 与 Claude Opus 结合用于漏洞研究时，我们遇到了几个困难。本节概述了主要问题，后续小节将描述我们如何解决或应对这些问题： **Token 限制：** 我使用的是 Claude Pro Max 订阅，这给代理在给定窗口内能做的事情设定了硬性上限。当代理读取源代码、生成测试程序并在数百次迭代中处理崩溃输出时，你会很快耗尽使用限制。在大型代码库中导航和审计需要要么有庞大的研究预算，要么有智能化的 token 使用策略。 **误报：** 与任何源代码分析工具一样，模型容易产生误报并得出错误结论。在没有先知或反馈机制的情况下，模型常常会自信地认为存在漏洞，但实际上并不存在。 **上下文窗口：** 由于上下文窗口的限制，你无法直接将整个 FreeBSD 源代码喂给模型。你需要谨慎地为模型提供多少上下文：上下文太少会导致误报或遗漏发现，而上下文太多则可能浪费 token 或导致模型性能下降。 **谄媚（Sycophancy）：** 提示词需要精心编写。当模型被赋予一个明确的目标或任务时，它会非常迫切地想要完成这个目标，即使这意味着凭空捏造或通过作弊手段来获取分析结果。例如，在一个场景中，模型找到了一种触发 use-after-free 漏洞的方法，但它是通过修改内核源代码来触发该漏洞的，因为该漏洞实际上无法从用户空间触发。 **作弊：** 模型容易错误描述问题、作弊，并在试图解决问题时产生“隧道视野”。例如，在一个场景中，我们让模型为开发一个从 FreeBSD 监狱中逃逸的利用程序构建 ROP 链。它找不到所需的 ROP 小工具，也没有考虑其他替代方案。相反，它编译并尝试加载一个包含所需小工具链的内核模块。 ## 应对 Token 限制 由于运行这些模型的硬件需求，使用它们进行漏洞研究存在明显的成本瓶颈和限制。对于这个项目，我们与大型实验室的研究方法之间的一个关键区别是：我们根本不愿意花费 2 万到 3 万美元的 token 费用去“可能”发现一个漏洞。我们希望使用上更具策略性，仅使用一个每月大约 100 美元的 Claude Pro Max 账户。 我们投入了大量时间来定制我们的 Claude 实例，以最大化像 Claude Code 这样的工具带来的价值。我们构建的工作流之一是一个深度研究工作流，允许代理执行广泛的在线研究，包括网页搜索、查阅过往学术论文、GitHub 上的现有源代码和 writeup。 在研究过程中，我们利用这个工作流来研究并构建了一个已知 FreeBSD 内核漏洞模式的数据库。这使我们能够识别代码中的危险函数或流程，进而用于代码库内的变体狩猎。 完成这个深度研究任务后，我们要求代理编写 CodeQL 和 semgrep 规则来识别潜在的易受攻击代码模式。这些规则由代理使用在深度研究阶段收集的关于已知易受攻击代码模式的数据设计而成。该过程如下图所示： 展示 AI 代理工作流用于寻找 FreeBSD 漏洞的图表：研究漏洞模式、编写静态规则、扫描源代码树、标记候选区域、以及对标记的代码进行分诊 将这些规则应用于整个代码库后，我们获得了数千个候选漏洞，然后可以要求代理进行分诊以确定其有效性。对于代码库中触发大量规则的模块，我们还要求代理对该模块内的代码进行深入审查。 注意：在将这种方法应用于其他目标时，需要注意 CodeQL 的许可证相当严格。在这个场景下，我们可以将其用于 FreeBSD，因为它是一个开源项目，但根据你的使用场景和其他情况，规则会变得相当严格。 ## 构建反馈循环 操作系统内核的美妙之处在于，我们寻找的许多漏洞都位于暴露给用户空间进程的用户空间到内核接口中。这是一个相当直接且文档完善的攻击面。此外，FreeBSD 原生支持像 KASAN 这样的检测框架，使得即使内存损坏漏洞没有立即导致崩溃，也能很容易地检测到它被触发。 这使得我们可以非常容易地构建一个与代理的反馈循环：我们可以为其提供对运行着带有 KASAN 支持的 FreeBSD 内核的虚拟机的访问权限。然后代理会利用这个环境作为先知来测试其关于漏洞存在性的假设。 下图展示了代理从审计转向假设，最后针对 KASAN 进行测试的工作流。除了确认漏洞存在之外，这对于代理迭代生成概念验证（PoC）重现程序也非常有用。 通常，当要求代理为潜在漏洞生成 KASAN 重现程序时，需要多次迭代才能生成。这使代理能够收集反馈并迭代，直到它确定问题不存在，或者成功修复相关 bug 并构建一个成功的重现程序。 用于确认 FreeBSD 漏洞的 KASAN 反馈循环流程图：代理审计源代码、编写触发程序、在带有检测功能的虚拟机中运行、检查 KASAN 遥测数据 总的来说，我们发现这种模式在围绕代理构建自动化以执行各种任务时非常有用。例如，我的同事 Michael Weber 最近构建了一个利用代理和一些自定义技能来规避基于签名和机器学习的检测机制 (https://www.praetorian.com/blog/llm-edr-signature-reduction/) 的反馈循环。我也在之前的一篇文章中写过类似的用于构建虚拟化加载器 (https://www.praetorian.com/blog/virtualized-loader-centurion/) 的反馈循环模式。 ## 管理上下文窗口限制 另一个关键方面是在利用代理进行代码审查时管理上下文窗口限制。进行这项研究时，我的一个假设是：对于一个模型来说，要有效地审计一个组件，当它能够理解并将代码库的大部分结构放入其上下文窗口时，效果可能最好。我认为，如果我将代理集中于一个特定的子系统，且该子系统具有合理的代码行数（例如 3 万到 4 万行），那么代理对大型系统的一个较小组件进行审计会容易得多。 作为该方法的一部分，我要求代理遍历代码库并识别出可供代理进行更深入审计的潜在候选者或子系统。这产生了一个候选子系统列表，我还结合了其他数据，例如子系统中危险 API 调用的数量以及暴露给用户态进程的攻击面大小。 我决定针对的一个更有趣领域是暴露给在 FreeBSD 监狱和 VNET 监狱中运行的受限进程的攻击面。在观看了 Ilja 和 Michael Smith 的 39C3 演讲《逃离容器：FreeBSD 监狱的安全分析》 (https://www.youtube.com/watch?v=obia_Ubu_Rw) 后，我产生了一个关于潜在攻击面进行研究的想法。 在演讲中，他们提到 FreeBSD 中有很多代码编写于 20 世纪 90 年代，那时监狱还不存在，并且编写时假设代码只由 root 用户帐号调用。然而，当 FreeBSD 监狱功能实现后，这个攻击面也暴露给了 FreeBSD 监狱内拥有 root 权限的任何用户。这一见解，加上 Claude Opus 所做的工作，使我能够识别出几个值得进行更深入审计的子系统。 在执行手动审计时，我尝试了几种提示代理的方法。在这个过程中，我观察到的一个现象是：要求代理审计并识别特定模块内的特定漏洞类别或模式，通常比使用更通用的提示（例如“在这个子系统中找到任何安全问题”）更有效。 ## 利用过程中的模型作弊实例 在这项研究中，我还观察到了许多模型在漏洞利用开发或发现过程中作弊的有趣实例。在一个实例中，模型试图为一个堆溢出漏洞构建 ROP 链。它未能找到触发栈迁移所需的小工具，于是通过编写并加载一个包含所需小工具（用于完成链）的自定义内核模块解决了问题，如下图所示： 终端表格显示了通过挂载文件系统镜像上的 SUID 载荷在 FreeBSD 14.4、OpenBSD 7.8 和 NetBSD 10.0 上获取 root shell 在我看来，这正是提示词结构和自定义框架在帮助减少作弊和误报方面发挥真正作用的地方。我认为，如果我们改用自定义框架构建工作流，采用多代理工作流，其中另一个 LLM 或一组 LLM 充当法官 (https://martinfowler.com/articles/harness-engineering.html#ComputationalVsInferential) 或同行，对提出的利用方案提供反馈，同时附带一个概述方案严格接受标准的强制性提示，那么这将使我们有可能解决工作流中的作弊问题。 在我看来，作弊也只是我们经常在模型中看到的谄媚行为的另一个例子：它们本质上非常非常想帮助你完成任务，即使这意味着以一种不合理的方式去做，或者完全破坏我们在利用过程中所依赖的前提条件。 ## 模型一方的谄媚与幻觉 我们发现的一个漏洞是影响 OpenBSD、NetBSD 和 FreeBSD 的文件系统驱动程序中的内存损坏漏洞。我们要求代理尝试将内存损坏漏洞转化为本地权限提升漏洞。 代理开发了一个“概念验证”利用程序，使其能够获得 root 权限。该漏洞涉及诱使用户挂载一个由攻击者控制的文件系统，且未设置 nosuid 标志。此时，攻击者可以在挂载的文件系统上运行 SUID 二进制文件以获得 root 权限。 在这种情况下，模型感到困惑，因为漏洞是文件系统驱动程序中的缓冲区越界读取，如果攻击者恰当地定位，他们可以从相邻文件中读取不适当的元数据，以控制二进制文件上的 SUID 标志。这使模型误以为这是一个安全问题，而没有意识到在没有 nosuid 标志的情况下挂载攻击者控制的文件系统是普遍危险的，并且不需要这种漏洞就能利用。 代理提出的利用方案，建议在 GENERIC FreeBSD 内核上使用自定义内核模块来提供缺失的 ROP 栈迁移小工具 这是一个有趣的失败案例，因为模型确实成功识别了文件系统驱动程序中的几个不可利用的内存损坏问题。它还能够通过以特定方式格式化文件系统来成功触发内存越界读取。然而，问题在于推理漏洞提供的原语所蕴含的含义时出现了偏差。 在这种情况下，模型有效地识别了一个有趣的边缘情况，但未能正确考虑利用所需的前提条件，以及这如何影响潜在漏洞或利用的整体有用性。如果攻击者能说服一个用户...（原文在此处截断，但根据上下文，后续内容应为“挂载文件系统而不设置 nosuid 标志，那么他们实际上已经可以执行任意代码了，根本不需要缓冲区越界读取这个漏洞。模型混淆了真正的漏洞与攻击场景中已经存在的固有危险性。”）