从Naptime到Big Sleep：使用大型语言模型捕获现实世界代码中的漏洞

2024/11/1 the Big Sleep team 模糊测试, 网络安全, 浏览器安全

引言

在我们之前的文章《Project Naptime：评估大型语言模型的攻击性安全能力》中，我们介绍了用于大型语言模型辅助漏洞研究的框架，并通过提升在Meta的CyberSecEval2基准测试上的最先进性能，展示了其潜力。自那时起，Naptime已演变为Big Sleep，这是Google Project Zero与Google DeepMind之间的合作项目。

今天，我们很高兴分享Big Sleep智能体发现的第一个真实世界漏洞：在广泛使用的开源数据库引擎SQLite中存在一个可利用的栈缓冲区下溢漏洞。我们在10月初发现该漏洞并报告给开发者，他们在同一天修复了它。幸运的是，我们在该问题出现在官方发布版本之前就发现了它，因此SQLite用户未受影响。

我们相信这是首个公开的AI智能体在广泛使用的真实世界软件中发现先前未知的可利用内存安全问题的例子。今年早些时候在DARPA AIxCC活动中，亚特兰大队在SQLite中发现了一个空指针解引用，这启发了我们将其用于测试，看看是否能发现更严重的漏洞。

我们认为这项工作具有巨大的防御潜力。在软件发布前就发现漏洞，意味着攻击者没有竞争空间：漏洞在攻击者有机会利用之前就被修复了。Fuzzing已经提供了巨大帮助，但我们需要一种方法能帮助防御者发现那些通过fuzzing难以（或不可能）发现的漏洞，我们期望AI能够缩小这一差距。我们认为这是最终扭转局势、为防御者实现不对称优势的一条有希望的道路。

这个漏洞本身相当有趣，而且SQLite现有的测试基础设施（包括通过OSS-Fuzz和项目自身的设施）都没有发现这个问题，因此我们进行了一些进一步的调查。

方法论

Naptime以及现在的Big Sleep的一个关键驱动因素是，针对先前发现并已修复漏洞的变体，持续在野外被发现利用。随着这一趋势的持续，很明显fuzzing未能成功捕获此类变体，而对于攻击者来说，手动变体分析是一种经济有效的方法。

我们还认为，与更通用的开放式漏洞研究问题相比，这种变体分析任务更适合当前的LLM。通过提供一个起点——例如先前已修复漏洞的详细信息——我们消除了漏洞研究中的许多模糊性，并从具体、有充分依据的理论出发："这是一个先前的漏洞；很可能在某个地方存在另一个类似的漏洞"。

我们的项目仍处于研究阶段，目前我们使用具有已知漏洞的小型程序来评估进展。最近，我们决定通过在SQLite上进行首次大规模、真实世界的变体分析实验来测试我们的模型和工具。我们收集了SQLite仓库的一些近期提交，手动移除了琐碎的和仅涉及文档的更改。然后，我们调整了提示，为智能体提供提交信息和变更的差异（diff），并要求智能体审查当前仓库（在HEAD处）是否存在可能尚未修复的相关问题。

发现的漏洞

这个漏洞很有趣，其中一个特殊的哨兵值-1被用于一个（在其他情况下）是索引类型的字段iColumn：

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未能正确处理这个边界情况，导致在处理对rowid列有约束的查询时，使用负索引向栈缓冲区写入。在我们提供给智能体的构建版本中，启用了调试断言，这个条件在第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列的约束将是一个很好的起点，但肯定需要更详细地阅读代码。智能体似乎已经比我们更了解SQLite，因此它可以走一些捷径！

一个常见的情况是，模型在生成测试用例时会立即使用generate_series虚拟表。（我们也看到过模型先研究可用的虚拟表的情况，但它显然能够在这里应用预先存在的知识）。

轨迹亮点

在这个基于Gemini 1.5 Pro的成功运行中，种子提交是[1976c3f7]；这是一个相当大且不明显的变更。我们的智能体发现的漏洞与种子提交中的变更只有松散的联系——这在手动变体分析中并不少见，理解代码库中的一个漏洞通常会引导研究人员发现其他问题。以下是选定的亮点，我们的评论以斜体显示——ASSISTANT块中的所有文本都直接来自智能体。

智能体对差异中的变更进行了合理的评估，并以此作为研究的起点：

ASSISTANT

该CL通过引入termFromWhereClause函数，改进了虚拟表查询中OR分支之间共享WHERE子句的处理。该函数从WhereClause中检索特定项，考虑嵌套子句。在此变更之前，由于项索引映射不正确，公共项可能未被正确处理，可能导致低效的查询计划或错误结果。最可能的漏洞将涉及allocateIndexInfo和whereLoopAddVirtualOne函数中WHERE子句约束的错误处理，CL已修改了如何使用新辅助函数处理约束偏移量。我将首先检查allocateIndexInfo函数...

在探索相关代码的几个（省略的）步骤之后，智能体形成了一个更具体的假设，并尝试通过运行补丁中测试用例的修改版本来检查它，但这没有成功，因为补丁中包含的测试用例依赖于我们配置中不可用的扩展：

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中设置断点...

智能体优雅地适应了这个挫折，认识到修复测试用例所需的步骤，几步之后，它已经检索到构建一个能到达whereLoopAddVirtualOne的测试用例所需的所有信息：

ASSISTANT

sqlite3_create_module函数注册虚拟表模块。shell.c文件包含几个这样的实例，包括generate_series、fsdir、completion和expert模块。json表看起来也很有趣。我将暂时专注于generate_series作为起点。我将尝试构建一个使用此模块并可能触发错误约束处理的查询...

...

请注意，在上述原始发现和漏洞复现过程中，智能体对于它试图触发的"错误约束处理"相当模糊；在这种情况下，完整的轨迹读起来有点像人类研究员——从一个想法开始，在调查中想到其他几个想法，最终产生一个复现了稍有不同的漏洞的测试用例。在这种情况下，当在generate_series表上调用whereLoopAddVirtualOne时，我们最终进入seriesBestIndex，在那里约束确实被错误处理。

然而，特别有趣的是，一旦程序崩溃，模型在解释事情方面做得更好——在生成根本原因分析和完整的崩溃报告时，我们可以看到智能体明确地构建了一个测试用例来触发特定的、已识别的边界情况：

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，从而引起断言失败。

那么Fuzzing呢？

鉴于复现案例的明显简单性，一个显而易见的问题是：为什么传统的fuzzing没有更早地发现这个漏洞？"简单"的答案在于fuzzing工具的配置。OSS-Fuzz使用的工具没有启用generate_series扩展，而替代的fuzzingshell.c工具包含一个旧版本的seriesBestIndex函数，不受该漏洞影响。虽然SQLite AFL仓库包含一个用于fuzzing我们提供给Big Sleep智能体的相同CLI二进制文件的配置，但它似乎没有被广泛使用。

为了理解这个漏洞是否真的"浅显"，我们尝试通过fuzzing重新发现它。我们遵循SQLite文档中的fuzzing说明，并使用CLI目标。在启动AFL运行之前，我们还验证了fuzzing语料库包含所需的generate_series和rowid关键字。然而，在150个CPU小时的fuzzing之后，该问题仍未发现。

然后，我们尝试通过例如向AFL的SQL字典添加必要的关键字来简化fuzzer的任务。然而，似乎只有当语料库包含非常接近崩溃输入的示例时，才能快速找到这个漏洞，因为代码覆盖率似乎不是这个特定问题的可靠指南。

诚然，AFL并不是最适合像SQL这样的基于文本格式的工具，因为大多数输入在语法上是无效的，会被解析器拒绝。尽管如此，将这个结果与Michal Zalewski 2015年关于fuzzing SQLite的博客文章进行比较是很有趣的。当时，AFL在发现SQLite中的漏洞方面相当有效；经过多年的fuzzing，该工具似乎已经达到了自然的饱和点。虽然到目前为止，与AFL发布时带来的有效性戏剧性飞跃相比，我们的结果似乎微不足道，但有趣的是，它有自己的优势，并且可能能够有效地发现一组不同的漏洞。

结论

对于团队来说，这是一个验证和成功的时刻——在一个广泛使用且经过充分fuzzing的开源项目中找到一个漏洞，这是一个令人兴奋的结果！当提供正确的工具时，当前的LLM可以进行漏洞研究。

然而，我们想重申，这些都是高度实验性的结果。Big Sleep团队的立场是，目前，针对特定目标的fuzzer很可能至少同样有效（在发现漏洞方面）。

我们希望未来这项工作能为防御者带来显著优势——不仅有可能发现崩溃的测试用例，还能提供高质量的根本原因分析，未来问题的分类和修复可能会更便宜、更有效。我们旨在继续分享我们在这一领域的研究，尽可能缩小公共最先进技术与私有最先进技术之间的差距。Big Sleep团队将继续在这一领域工作，推进Project Zero让0-day变得困难的使命。

Big Sleep团队

这不再仅仅是Project Zero的努力，所有为此做出贡献的人员如下（按字母顺序排列）：

Miltos Allamanis, Martin Arjovsky, Charles Blundell, Lars Buesing, Mark Brand, Sergei Glazunov, Dominik Maier, Petros Maniatis, Guilherme Marinho, Henryk Michalewski, Koushik Sen, Charles Sutton, Vaibhav Tulsyan, Marco Vanotti, Theophane Weber, Dan Zheng

标签: #安全漏洞 #Fuzzing #漏洞利用 #Web安全