谷歌內(nèi)部項目：大模型 AI 智能體發(fā)現(xiàn)了代碼漏洞
開源數(shù)據(jù)庫引擎 SQLite 有 bug，還是智能體檢測出來的！
通常，軟件開發(fā)團隊會在軟件發(fā)布之前發(fā)現(xiàn)軟件中的漏洞，讓攻擊者沒有破壞的余地。模糊測試 （Fuzzing）是一種常見的軟件測試方法，其核心思想是將自動或半自動生成的隨機數(shù)據(jù)輸入到一個程序中，并監(jiān)視程序異常。
盡管模糊測試大有幫助，但有些漏洞難以甚至不可能通過模糊測試發(fā)現(xiàn)。
谷歌內(nèi)部有一個名為 Project Zero 的軟件安全研究團隊，他們發(fā)現(xiàn)隨著大型語言模型 (LLM) 的代碼理解和一般推理能力的提高，LLM 將能夠在識別和展示安全漏洞時重現(xiàn)人類安全研究人員的系統(tǒng)方法，最終彌補當前自動漏洞發(fā)現(xiàn)方法的一些盲點。
Project Zero 在 6 月介紹了 LLM 輔助漏洞研究框架 ——Naptime 架構(gòu)，之后 Naptime 演變成了 Big Sleep 智能體，由 Google Project Zero 和 Google DeepMind 合作完成。
Naptime 架構(gòu)
研究團隊認為：與開放式漏洞研究相比，變體分析任務(wù)更適合當前的 LLM。通過提供一個起點（例如之前修復(fù)的漏洞的詳細信息），可以消除漏洞研究中的很多歧義：「這是一個以前的錯誤；某個地方可能還有另一個類似的錯誤。」
現(xiàn)在，Big Sleep 智能體發(fā)現(xiàn)了第一個現(xiàn)實軟件漏洞：SQLite 中可利用堆棧緩沖區(qū)下溢。
研究團隊收集了 SQLite 存儲庫中最近的一些提交，手動刪除了瑣碎的和僅用于文檔的更改，然后調(diào)整了 prompt，為智能體提供提交消息（commit message）和更改的差異，要求智能體檢查當前存儲庫是否存在可能尚未修復(fù)的相關(guān)問題。
簡單來說，SQLite 這個漏洞是在索引類型字段 iColumn 中使用了特殊的 sentinel 值 -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 */這創(chuàng)建了一個潛在的邊緣情況，而函數(shù) seriesBestIndex 無法正確處理這種邊緣情況，導致在處理對 rowid 列有約束的查詢時，將負索引寫入堆棧緩沖區(qū)。在研究團隊提供給智能體的構(gòu)建中，啟用了調(diào)試斷言（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 }然而，實際上這個斷言并不存在，因此該漏洞可能會被惡意利用。幸運的是，該團隊在正式版本出現(xiàn)之前就發(fā)現(xiàn)了這個問題，因此 SQLite 用戶沒有受到影響。
毫無疑問的是，智能體在這次漏洞查找中起了關(guān)鍵作用，這也表明智能體在軟件安全方面具備很大的應(yīng)用潛力。
參考鏈接：https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html
