谷歌內部專案:大模型AI智慧體發現了程式碼漏洞

机器之心發表於2024-11-02
開源資料庫引擎 SQLite 有 bug,還是智慧體檢測出來的!

通常,軟體開發團隊會在軟體釋出之前發現軟體中的漏洞,讓攻擊者沒有破壞的餘地。模糊測試 (Fuzzing)是一種常見的軟體測試方法,其核心思想是將自動或半自動生成的隨機資料輸入到一個程式中,並監視程式異常。

儘管模糊測試大有幫助,但有些漏洞難以甚至不可能透過模糊測試發現。

谷歌內部有一個名為 Project Zero 的軟體安全研究團隊,他們發現隨著大型語言模型 (LLM) 的程式碼理解和一般推理能力的提高,LLM 將能夠在識別和展示安全漏洞時重現人類安全研究人員的系統方法,最終彌補當前自動漏洞發現方法的一些盲點。

Project Zero 在 6 月介紹了 LLM 輔助漏洞研究框架 ——Naptime 架構,之後 Naptime 演變成了 Big Sleep 智慧體,由 Google Project Zero 和 Google DeepMind 合作完成。
圖片
Naptime 架構

研究團隊認為:與開放式漏洞研究相比,變體分析任務更適合當前的 LLM。透過提供一個起點(例如之前修復的漏洞的詳細資訊),可以消除漏洞研究中的很多歧義:「這是一個以前的錯誤;某個地方可能還有另一個類似的錯誤。」

現在,Big Sleep 智慧體發現了第一個現實軟體漏洞:SQLite 中可利用堆疊緩衝區下溢。

研究團隊收集了 SQLite 儲存庫中最近的一些提交,手動刪除了瑣碎的和僅用於文件的更改,然後調整了 prompt,為智慧體提供提交訊息(commit message)和更改的差異,要求智慧體檢查當前儲存庫是否存在可能尚未修復的相關問題。

簡單來說,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 */

這建立了一個潛在的邊緣情況,而函式 seriesBestIndex 無法正確處理這種邊緣情況,導致在處理對 rowid 列有約束的查詢時,將負索引寫入堆疊緩衝區。在研究團隊提供給智慧體的構建中,啟用了除錯斷言(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 }

然而,實際上這個斷言並不存在,因此該漏洞可能會被惡意利用。幸運的是,該團隊在正式版本出現之前就發現了這個問題,因此 SQLite 使用者沒有受到影響。

毫無疑問的是,智慧體在這次漏洞查詢中起了關鍵作用,這也表明智慧體在軟體安全方面具備很大的應用潛力。

參考連結:
https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html

相關文章