《從營銷AIGC化到AIGC營銷化》報告發布
來源：清元宇宙7月2日上午，清華大學元宇宙文化實驗室舉辦元宇宙在線沙龍“AIGC熱潮與應用”。會議中，清華大學新聞與傳播學院教授、元宇宙文化實驗室主任、新媒體研究
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 代碼理解和一般推理能力的提高，谷歌研究者一直在探索這些模型如何在識別和演示安全漏洞時，重新人類安全研究人員的方法。
在《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：
7476structsqlite3_index_constraint{7477intiColumn7478unsignedcharop7479unsignedcharusable7480intiTermOffset7481}*aConstraint這種模式產生了一個邊緣案例，所有使用該字段的代碼都需要正確處理這種情況，因為按照常規預期，有效的列索引值應該是非負的。
seriesBestIndex 函數在處理這個 edge case 時存在缺陷，當處理包含 rowid 列約束的查詢時，導致寫入了帶有負索引的堆棧緩沖區。
在研究者提供給 AI Agent 的編譯版本中，debug assertion 功能已啟用，這種異常情況會被第 706 行的斷言檢查所捕獲：
619staticintseriesBestIndex(620sqlite3_vtab*pVTab,621sqlite3_index_info*pIdxInfo622){...630intaIdx[7];/*Constraintsonstart,stop,step,LIMIT,OFFSET,631**andvalue.aIdx[5]coversvalue=,value>=,and632**value>,aIdx[6]coversvalue<=andvalue<*/633conststructsqlite3_index_constraint*pConstraint;...642for(i=0;i<pIdxInfo->nConstraint;i++,pConstraint++){643intiCol;644intiMask;645intop=pConstraint->op;...705iCol=pConstraint->iColumn-SERIES_COLUMN_START;706assert(iCol>=0&&iCol<=2);707iMask=1<<iCol;...713if(pConstraint->usable==0){714unusableMask|=iMask;715continue;716}elseif(op==SQLITE_INDEX_CONSTRAINT_EQ){717idxNum|=iMask;718aIdx[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 是谷歌 DeepMind 的研究工程師，從事代碼和軟件工程的機器學習，以及編程語言的研究。
此前，他曾參與 Swift for TensorFlow 的工作，專注于 Swift 中的可微分編程。
他在普渡大學獲得了計算機科學專業的學士學位。畢業后，他做了多年的學生研究員，期間研究成果頗豐。
參考資料：
https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html
本文來自微信公眾號：微信公眾號（ID：null），作者：新智元
本文鏈接：http://www.tebozhan.com/showinfo-45-9382-0.html谷歌 Agent 首次發現真實世界代碼漏洞：搶救全球數億設備，有望挽回數十億美元損失
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號