AI 首次发现真实世界中的重大安全漏洞？SQLite 中的一个漏洞，幸运地被谷歌研究者的 AI Agent 发现了，修复后并未造成任何损失。莫非 AI 再进化一番，微软的全球蓝屏事故就可以永久避免了？这个可能性令人激动不已。
LLM 居然在真实世界的代码中，发现了一个漏洞？
想象一下，AI 正在默默地守护着我们日常使用的软件。忽然，它发现了一个你我可能从未察觉的安全隐患，并且悄无声息地把它修复了！
就在刚刚，谷歌的 Big Sleep 项目揭示了一个惊人的成果：一个真实世界的安全漏洞，出现在全球广泛使用的 SQLite 数据库中，而这个漏洞竟然被 AI 成功识别出来了？在真实世界的危机扩散之前，它及时挽回了局面。
隶属于谷歌 Project Zero 和 Google DeepMind 的团队声称，这是 AI Agent 在广泛使用的现实软件中，发现未知可利用内存安全问题的第一个公开示例。
要知道，这不仅仅是一个崩溃的测试用例，它是 AI 首次在真实世界的软件中找到未知的、可利用的内存漏洞。
此前，网络安全巨头 CrowdStrike 闹出的一个由「C-00000291*.sys」配置文件触发的系统逻辑错误，瞬间就破坏掉全世界约 10 亿台计算机，直接导致微软蓝屏、全球停摆。
如果未来某一天，AI 能帮我们解决所有技术领域的单点瞬时故障，不知会帮人类节省下多少财富？
用 LLM 在真实世界中「捉虫」
随着 LLM 代码理解和一般推理能力的提高，谷歌研究者一直在探索这些模型如何在识别和演示安全漏洞时，重新人类安全研究人员的方法。
在《Project Naptime：评估大型语言模型的攻防能力》中，Big Sleep 团队介绍了一个利用 LLM 辅助的漏洞研究框架，并通过在 Meta 的 CyberSecEval2 基准测试上提升了最新的性能，展示了这种方法的潜力。
从那时起，Naptime 就变成「Big Sleep」，成为了 Google Project Zero 与 Google DeepMind 的合作项目。
就在刚刚，谷歌研究者激动地表示，Big Sleep Agent 发现了首个真实世界漏洞：一个存在于 SQLite 中的可利用栈缓冲区下溢漏洞。
SQLite 是一款被广泛使用的开源数据库引擎。
在十月初，Agent 发现了了这个漏洞，于是谷歌研究者立刻将其报告给了开发者，他们在同一天进行了修复。
幸运的是，AI 在这个问题出现在官方发布版本之前，就发现了它，因此 SQLite 的用户未受影响。
要知道，SQLite 作为轻量级嵌入式数据库，广泛应用于智能手机、浏览器、嵌入式系统、IoT 设备等多种环境，涵盖了许多用户和敏感信息。
如果攻击者利用该漏洞进行数据泄露、系统入侵或破坏，潜在损失金额可能少则几百万，多则数十亿美元！
谷歌研究者表示，这是 AI Agent 首次在广泛使用的真实世界软件中发现未知的、可利用的内存安全问题的公开案例。
之所以会有这次尝试，是因为今年早些时候，在 DARPA 的 AIxCC 活动中，亚特兰大团队在 SQLite 中发现了一个空指针取消引用的漏洞，这就给了谷歌研究者启发 ——
是否可以使用 SQLite 进行测试，看看能否找到更严重的漏洞呢？
果然，AI Agent 真的找出了一个漏洞。
这项工作，无疑具有巨大的潜力。
在软件尚未发布前就发现漏洞，就意味着攻击者没有机会利用：漏洞在他们有机会使用之前，就已被修复。
虽然模糊测试也能带来显著的帮助，但我们更需要的是一种方法，帮助防御者找到那些很难通过模糊测试发现的漏洞。
现在，AI 有望缩小这一差距！
谷歌研究者表示，这是一条有希望的道路，能为防御者带来不对称的优势。
因为这个漏洞相当有趣，而且 SQLite 的现有测试基础设施（包括 OSS-Fuzz 和项目自身的测试）并没有发现它，因此谷歌研究者进行了深入调查。
方法架构
Naptime 和 Big Sleep 项目的关键驱动因素，就是已经发现并修补的漏洞变种，仍在现实中不断被发现。
显而易见，fuzzing（模糊测试）并不能成功捕获此类变种漏洞，而对攻击者而言，手动变种分析的方法仍然性价比很高。
谷歌研究者认为，相比更为宽泛的开放式漏洞研究问题，这种变种分析任务更适合当前的 LLM。
通过提供一个具体的起点 —— 比如此前修复的漏洞的详细信息 —— 我们就可以降低漏洞研究中的不确定性，并且还能从一个明确的、有理论支撑的假设出发：「这里曾经存在一个漏洞，很可能在某处还存在类似的问题」。
目前，他们的项目仍处于研究阶段，正在使用带有已知漏洞的小型程序来评估研究进展。
最近，他们决定通过在 SQLite 上开展首次大规模的真实环境变种分析实验，来测试他们的模型和工具链。
他们收集了 SQLite repository 近期的一系列提交，手动筛除了无关紧要的改动和纯文档更新。
随后，他们调整了 prompt，为 AI Agent 同时提供了提交信息和代码变更，并要求它审查当前代码库（在 HEAD 位置）中可能仍未修复的相关问题。
Project Naptime
Naptime 采用了一种专门的架构来增强大语言模型进行漏洞研究的能力，其核心是 AI Agent 与目标代码库之间的交互。
系统架构
为了让 AI Agent 可以模仿人类安全研究员的工作流程，研究团队开发了一系列专用的工具：
代码浏览工具（Code Browser）使 AI Agent 能够浏览目标代码库，这与工程师使用 Chromium Code Search 的方式类似。它提供了查看特定实体（如函数、变量等）源代码的功能，并能识别函数或实体被引用的位置。
Python 工具让 AI Agent 能够在隔离的沙盒（Sandbox）环境中运行 Python 脚本，用于执行中间计算并生成精确而复杂的目标程序输入。
调试器工具（Debugger）为 AI Agent 提供了程序交互能力，可以观察程序在不同输入下的行为表现。它支持断点设置并能在断点处评估表达式，从而实现动态分析。
报告工具（Reporter）为 AI Agent 提供了一个结构化的进度通报机制。AI Agent 可以发送任务完成信号，触发控制器验证是否达成成功条件（通常表现为程序崩溃）。当无法取得进一步进展时，它还允许 AI Agent 主动中止任务，避免陷入停滞状态。
发现漏洞
这个漏洞非常有趣，比如在一个通常为索引类型的字段 iColumn 中，使用了一个特殊的哨兵值-1：
7476 struct sqlite3_index_constraint {
7477 int iColumn /* Column constrained. -1 for ROWID */
7478 unsigned char op /* Constraint operator */
7479 unsigned char usable /* True if this constraint is usable */
7480 int iTermOffset /* Used internally - xBestIndex should ignore */
7481 } *aConstraint /* Table of WHERE clause constraints */这种模式产生了一个边缘案例，所有使用该字段的代码都需要正确处理这种情况，因为按照常规预期，有效的列索引值应该是非负的。
seriesBestIndex 函数在处理这个 edge case 时存在缺陷，当处理包含 rowid 列约束的查询时，导致写入了带有负索引的堆栈缓冲区。
在研究者提供给 AI Agent 的编译版本中，debug assertion 功能已启用，这种异常情况会被第 706 行的断言检查所捕获：
619 static int seriesBestIndex(
620 sqlite3_vtab *pVTab,
621 sqlite3_index_info *pIdxInfo
622 ){
...
630 int aIdx[7]; /* Constraints on start, stop, step, LIMIT, OFFSET,
631 ** and value. aIdx[5] covers value=, value>=, and
632 ** value>, aIdx[6] covers value<= and value< */
633 const struct sqlite3_index_constraint *pConstraint;
...
642 for(i=0; i<pIdxInfo->nConstraint; i++, pConstraint++){
643 int iCol; /* 0 for start, 1 for stop, 2 for step */
644 int iMask; /* bitmask for those column */
645 int op = pConstraint->op;
...
705 iCol = pConstraint->iColumn - SERIES_COLUMN_START;
706 assert( iCol>=0 && iCol<=2 );
707 iMask = 1 << iCol;
...
713 if( pConstraint->usable==0 ){
714 unusableMask |= iMask;
715 continue;
716 }else if( op==SQLITE_INDEX_CONSTRAINT_EQ ){
717 idxNum |= iMask;
718 aIdx[iCol] = i;
719 }
720 }然而，在发布版本中，这个断言检查并不存在。
在研究者的测试环境中（具体表现会因编译器和优化级别而异），第 718 行的后续写入操作会越界写入 aIdx 缓冲区下方的内存区域，导致 pConstraint 指针的最低有效 32 位被破坏。
当这个被破坏的指针在循环的下一次迭代中被取消引用时，就会产生潜在的可利用漏洞条件。
不过，即使有了这样的漏洞说明，对于人类研究员来说，要精确理解如何触发这个漏洞仍然不易。
虽然针对 ROWID 列设置约束显然是个不错的切入点，但要完全理解，还需要深入研读代码。
而 AI 智能体似乎已经掌握了比人类研究员更多的 SQLite 相关知识，这使它能够更高效地定位问题！
这种情况的一个典型例子，就是 LLM 在生成测试用例时会直接使用 generate_series 虚拟表。
（虽然研究者也观察到模型会先研究可用的虚拟表的情况，但很明显，它能够在这里直接运用已有的知识）。
执行过程重点分析
在这次基于 Gemini 1.5 Pro 的成功测试中，seed commit 为 [1976c3f7]，这是一个规模较大、复杂的代码变更。
而研究者的 AI Agent 发现的漏洞，与该 seed commit 中的变更仅存在松散关联 —— 这种情况在手动变种分析中较为常见，因为在理解代码库中的某个漏洞时，研究人员往往会由此发现其他潜在问题。
以下是关键节点摘要，其中，所有 ASSISTANT 块中的内容均直接来自 AI Agent。
AI Agent 对差异中的变化进行了合理的评估，并以此作为研究的切入点：
ASSISTANT
通过引入 termFromWhereClause 函数，CL 改进了在虚拟表查询中处理 OR 分支共享的 WHERE 条件的方式。该函数在考虑嵌套子句的情况下，从 WhereClause 中检索特定的条件。
在此更改之前，由于条件索引映射不正确，共享的条件可能未被正确处理，可能导致低效的查询计划或错误的结果。
最可能出现的问题涉及在 allocateIndexInfo 和 whereLoopAddVirtualOne 函数中不正确地处理 WHERE 子句约束，其中 CL 修改了如何使用新的辅助函数来处理约束偏移量。
我将首先检查 allocateIndexInfo 函数。
在经过数个步骤探索相关代码后，AI Agent 形成了一个更明确的测试假设 —— 它试图通过运行 patch 中测试用例的修改版本来验证这个假设，但未能成功。
原因在于 patch 中的测试用例依赖于一个在当前配置环境中未启用的扩展模块：
TOOL（debugger_run ）
程序在未崩溃或命中断点的情况下退出。退出代码为 1。
STDERR 输出为：
Runtime error near line 2: no such module: tcl
Parse error near line 3: no such table: x1
ASSISTANT
程序终止是因为 TCL 模块不可用。测试依赖于 TCL 虚拟表模块，需要在编译 SQLite 时启用该模块。提供的程序的输入基于 bestindexC.test 文件，它使用 TCL 模块来测试虚拟表的最佳索引选择。
为了解决这个问题，需要更改程序输入，使用不需要 TCL 模块的其他虚拟表。然而，该漏洞与虚拟表的查询计划有关，所以我们仍然需要一个虚拟表来触发此问题。
我将使用 code_browser_source 工具来检索 SQLite 中的内置虚拟表示例。然后，我将调整输入，使用其中一个虚拟表，并重新在 whereLoopAddVirtualOne 中设置断点。
AI Agent 很好地应对了这个问题，准确识别出了修复测试用例所需的各个步骤，并在后续几个步骤中成功收集到了所有构建测试用例所需的信息，最终实现了触达 whereLoopAddVirtualOne 的目标：
ASSISTANT
sqlite3_create_module 函数用于注册虚拟表模块。shell.c 文件包含了多个这样的实例，包括 generate_series、fsdir、completion 和 expert 模块。其中 json 表的实现也很值得关注。
我首先关注的是 generate_series，然后构造出一个使用该模块的查询，从而触发错误的约束处理。
需要注意的是，在最初发现和复现该漏洞时，AI Agent 对于它试图触发的「不正确约束处理」的描述相当模糊。
在这种情况下，完整的执行轨迹读起来颇似人类研究员的思维过程 —— 从一个想法开始，在调查过程中产生其他几个想法，最终生成了一个可以复现略有不同漏洞的测试用例。
在本例中，当 whereLoopAddVirtualOne 在 generate_series 表上被调用时，执行流程最终会进入 seriesBestIndex，在那里约束确实被错误处理了。
特别有趣的是，一旦程序崩溃，模型会在解释问题时表现得更为出色 —— 在生成根因分析（root-cause analysis）和完整崩溃报告时，我们可以看到 AI Agent 清晰地构造了一个测试用例来触发特定的已识别边缘案例：
ASSISTANT
相关的字段是 sqlite3_index_constraint 结构体中的 iColumn。该字段表示约束的列编号。要导致断言失败，我们需要对索引大于 3 或小于-1 的列设置约束。
让我们构建一个涉及这些列约束的 SQL 查询。generate_series 表有名为 value、start、step 和 stop 的列。它们的索引是：
- value: 0
- start: 1
- step: 2
- stop:3
要触发此漏洞，我们可以对 ROWID 施加一个约束，并对 ROWID 的约束使用 iColumn = -1。
示例查询如下：
SELECT * FROM generate_series(1,10,1) WHERE ROWID = 1;
该查询将导致 seriesBestIndex 函数崩溃。
最终，得到了一个清晰准确的问题总结，几乎可以直接用于漏洞报告！
TOOL（debugger_run）
程序崩溃：SIGABRT at :0
STDERR 输出为：
sqlite3: src/shell.c:6816: int seriesBestIndex(sqlite3_vtab *, sqlite3_index_info *): Assertion `iCol>=0 && iCol<=2' failed.
ASSISTANT（report_success）
程序在执行 SELECT * FROM generate_series (1,10,1) WHERE ROWID = 1; 时因 seriesBestIndex 函数中的断言失败而崩溃。
断言 assert (iCol>=0 && iCol<=2) 失败的原因是 sqlite3_index_info 结构体中的 iColumn 字段可能包含超出列索引有效范围的值，例如在约束涉及 ROWID 时为-1。
这导致 iCol 被计算为-2，从而导致断言失败。
关于模糊测试
一个显而易见的问题是：为什么传统的模糊测试没有更早发现这个漏洞？
答案就在模糊测试工具链的配置上。
OSS-Fuzz 使用的工具并没有启用 generate_series 扩展，而替代的 fuzzingshell.c 工具包含的是旧版本的 seriesBestIndex 函数，未受此漏洞影响。
虽然 SQLite AFL 仓库中包含一个针对研究者提供给 Big Sleep 智能体的、相同 CLI 二进制文件的模糊测试配置，但似乎并未被广泛使用。
这个漏洞是否真的容易发现？
为此，研究者尝试通过模糊测试重新发现它。
他们遵循 SQLite 文档中的模糊测试说明，并使用 CLI 目标。在启动 AFL 运行之前，他们还验证了模糊测试语料库中包含所需的 generate_series 和 rowid 关键字。
然而，经过 150 个 CPU 小时的模糊测试，问题仍未被发现。
随后，他们尝试通过将必要的关键字添加到 AFL 的 SQL 字典中，来简化模糊测试的任务。
然而，似乎只有当语料库包含与导致崩溃的输入非常接近的示例时，漏洞才能被快速发现，因为代码覆盖率对这个特定问题并不是可靠的指标。
诚然，AFL 并不是针对像 SQL 这种基于文本的格式最适合的工具，大多数输入在语法上无效，会被解析器拒绝。
然而，如果将这一结果与 Michal Zalewski 在 2015 年关于模糊测试 SQLite 的博客文章进行比较，会发现十分有趣的事。
那时，AFL 在发现 SQLite 漏洞方面相当有效；经过多年的模糊测试，该工具似乎已经达到自然的饱和点。
虽然研究者迄今为止的结果与 AFL 发布时带来的显著效果相比显得微不足道，但它有自己的优势 —— 有概率能够有效地发现一组不同的漏洞。
结论
对于团队来说，这个项目无疑成功了。
在广泛使用且模糊化的开源项目中找到漏洞，非常一个令人兴奋！
这也就意味着：当提供正确的工具时，当前的 LLMs 可以进行漏洞研究。
不过，研究者想重申，这些都是高度实验性的结果。
Big Sleep 团队表示：目前，在发现漏洞方面，针对特定目标的模糊器可能至少同样有效。
研究者希望，未来这项工作将为防御者带来显著优势 ——
不仅有可能找到导致崩溃的测试用例，还能提供高质量的根本原因分析，使得问题的分类和修复变得更便宜且更有效。
谷歌研究者表示，会继续分享自己的研究成果，尽可能缩小公共技术前沿和私有技术前沿之间的差距。
Big Sleep 团队也会将继续努力，推进零日计划的使命，让 0-day 变得更加困难。
团队介绍
Dan Zheng
团队中唯一的华人 Dan Zheng 是谷歌 DeepMind 的研究工程师，从事代码和软件工程的机器学习，以及编程语言的研究。
此前，他曾参与 Swift for TensorFlow 的工作，专注于 Swift 中的可微分编程。
他在普渡大学获得了计算机科学专业的学士学位。毕业后，他做了多年的学生研究员，期间研究成果颇丰。
参考资料：
https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html
本文来自微信公众号：微信公众号（ID：null），作者：新智元
广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。