谷歌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可以模仿人類安全研究員的工作流程，研究團隊開發了一系列專用的工具：
代碼瀏覽工具（Code Browser）使AI Agent能夠瀏覽目標代碼庫，這與工程師使用Chromium Code Search的方式類似。它提供了查看特定實體（如函數、變量等）源代碼的功能，並能識別函數或實體被引用的位置。
Python工具讓AI Agent能夠在隔離的沙盒（Sandbox）環境中運行Python腳本，用於執行中間計算並生成精確而複雜的目標程序輸入。
調試器工具（Debugger）爲AI Agent提供了程序交互能力，可以觀察程序在不同輸入下的行爲表現。它支持斷點設置並能在斷點處評估表達式，從而實現動態分析。
報告工具（Reporter）爲AI Agent提供了一個結構化的進度通報機制。AI Agent可以發送任務完成信號，觸發控制器驗證是否達成成功條件（通常表現爲程序崩潰）。當無法取得進一步進展時，它還允許AI Agent主動中止任務，避免陷入停滯狀態。
發現漏洞
這個漏洞非常有趣，比如在一個通常爲索引類型的字段iColumn中，使用了一個特殊的哨兵值-1：
這種模式產生了一個邊緣案例，所有使用該字段的代碼都需要正確處理這種情況，因爲按照常規預期，有效的列索引值應該是非負的。
seriesBestIndex函數在處理這個edge case時存在缺陷，當處理包含rowid列約束的查詢時，導致寫入了帶有負索引的堆棧緩衝區。
在研究者提供給AI Agent的編譯版本中，debug assertion功能已啓用，這種異常情況會被第706行的斷言檢查所捕獲：
然而，在發佈版本中，這個斷言檢查並不存在。
在研究者的測試環境中（具體表現會因編譯器和優化級別而異），第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
在經過數個步驟探索相關代碼後，AI Agent形成了一個更明確的測試假設——它試圖通過運行patch中測試用例的修改版本來驗證這個假設，但未能成功。
原因在於patch中的測試用例依賴於一個在當前配置環境中未啓用的擴展模塊：
TOOL（debugger_run ）
ASSISTANT
AI Agent很好地應對了這個問題，準確識別出了修復測試用例所需的各個步驟，並在後續幾個步驟中成功收集到了所有構建測試用例所需的信息，最終實現了觸達whereLoopAddVirtualOne的目標：
ASSISTANT
需要注意的是，在最初發現和復現該漏洞時，AI Agent對於它試圖觸發的「不正確約束處理」的描述相當模糊。
在這種情況下，完整的執行軌跡讀起來頗似人類研究員的思維過程——從一個想法開始，在調查過程中產生其他幾個想法，最終生成了一個可以復現略有不同漏洞的測試用例。
在本例中，當whereLoopAddVirtualOne在generate_series表上被調用時，執行流程最終會進入seriesBestIndex，在那裡約束確實被錯誤處理了。
特別有趣的是，一旦程序崩潰，模型會在解釋問題時表現得更爲出色——在生成根因分析（root-cause analysis）和完整崩潰報告時，我們可以看到AI Agent清晰地構造了一個測試用例來觸發特定的已識別邊緣案例：
ASSISTANT
最終，得到了一個清晰準確的問題總結，幾乎可以直接用於漏洞報告！
TOOL（debugger_run）
ASSISTANT（report_success）
關於模糊測試
一個顯而易見的問題是：爲什麼傳統的模糊測試沒有更早發現這個漏洞？
答案就在模糊測試工具鏈的配置上。
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