通信人家园

标题: 谷歌Agent首次发现真实世界代码漏洞！抢救全球数亿设备，或挽回数十亿美元  [查看完整版帖子] [打印本页]
时间:  2024-11-2 13:35
作者: see122     标题: 谷歌Agent首次发现真实世界代码漏洞！抢救全球数亿设备，或挽回数十亿美元


新智元报道  

编辑：Aeneas 好困

【新智元导读】AI首次发现真实世界中的重大安全漏洞？SQLite中的一个漏洞，幸运地被谷歌研究者的AI Agent发现了，修复后并未造成任何损失。莫非AI再进化一番，微软的全球蓝屏事故就可以永久避免了？这个可能性令人激动不已。

LLM居然在真实世界的代码中，发现了一个漏洞？

想象一下，AI正在默默地守护着我们日常使用的软件。忽然，它发现了一个你我可能从未察觉的安全隐患，并且悄无声息地把它修复了！

就在刚刚，谷歌的Big Sleep项目揭示了一个惊人的成果：一个真实世界的安全漏洞，出现在全球广泛使用的SQLite数据库中，而这个漏洞竟然被AI成功识别出来了？在真实世界的危机扩散之前，它及时挽回了局面。

隶属于谷歌Project Zero和Google DeepMind的团队声称，这是AI Agent在广泛使用的现实软件中，发现未知可利用内存安全问题的第一个公开示例。

要知道，这不仅仅是一个崩溃的测试用例，它是AI首次在真实世界的软件中找到未知的、可利用的内存漏洞。

如果未来某一天，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可以模仿人类安全研究员的工作流程，研究团队开发了一系列专用的工具：

发现漏洞

这个漏洞非常有趣，比如在一个通常为索引类型的字段iColumn中，使用了一个特殊的哨兵值-1：

<pre><code>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 */</code></pre> 这种模式产生了一个边缘案例，所有使用该字段的代码都需要正确处理这种情况，因为按照常规预期，有效的列索引值应该是非负的。

seriesBestIndex函数在处理这个edge case时存在缺陷，当处理包含rowid列约束的查询时，导致写入了带有负索引的堆栈缓冲区。

在研究者提供给AI Agent的编译版本中，debug assertion功能已启用，这种异常情况会被第706行的断言检查所捕获：

<pre><code>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&gt;=, and
632 ** value&gt;, aIdx[6] covers value&lt;= and value&lt; */
633 const struct sqlite3_index_constraint *pConstraint;
...
642 for(i=0; i 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-&gt;op;
...
705 iCol = pConstraint-&gt;iColumn - SERIES_COLUMN_START;
706 assert( iCol&gt;=0 && iCol&lt;=2 );
707 iMask = 1 &lt;&lt; iCol;
...
713 if( pConstraint-&gt;usable==0 ){
714 unusableMask |= iMask;
715 continue;
716 }else if( op==SQLITE_INDEX_CONSTRAINT_EQ ){
717 idxNum |= iMask;
718 aIdx[iCol] = i;
719 }
720 }</code></pre> 然而，在发布版本中，这个断言检查并不存在。

在研究者的测试环境中（具体表现会因编译器和优化级别而异），第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&gt;=0 &&  iCol&lt;=2' failed.
ASSISTANT（report_success）

程序在执行SELECT * FROM generate_series(1,10,1) WHERE ROWID = 1;时因seriesBestIndex函数中的断言失败而崩溃。 断言assert(iCol&gt;=0 && iCol&lt;=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


来源：网易





通信人家园 (https://www.txrjy.com/) Powered by C114