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