Move語言引用安全模塊中的整數溢出漏洞分析

近期，我們在深入研究Aptos Moveevm時發現了一個新的整數溢出漏洞。這個漏洞的觸發過程相當有趣，下面我們將深入分析這個漏洞，並借此機會探討Move語言的一些核心概念。

Move語言在執行字節碼之前會進行代碼單元驗證，這個過程分爲四個步驟。本文討論的漏洞出現在reference_safety步驟中。

reference_safety模塊主要負責驗證代碼中的引用安全性，包括檢查是否存在懸空引用、可變引用訪問是否安全、全局存儲引用訪問是否合規等。

在引用安全驗證過程中，系統會對每個基本塊進行分析。基本塊是指除入口和出口外沒有分支指令的代碼序列。Move語言通過遍歷字節碼，查找所有分支指令和循環指令序列來識別基本塊。

Move語言支持兩種引用類型：不可變引用(&)和可變引用(&mut)。不可變引用用於讀取數據，可變引用用於修改數據。這種設計有助於提高代碼的安全性和可讀性。

引用安全驗證的主要流程包括：掃描函數中的基本塊，分析字節碼指令，判斷所有引用操作是否合法。這個過程使用AbstractState結構體，其中包含borrow graph和locals，共同確保函數中的引用安全性。

驗證過程中會比較執行基本塊前後的狀態(pre state和post state)，並將結果合並以更新塊狀態。如果狀態發生變化且當前塊存在指向自身的後向邊（表示存在循環），則會重新執行該基本塊，直到狀態不再變化或出現錯誤。

漏洞出現在判斷join結果是否改變的過程中。當函數參數長度和局部變量長度之和超過256時，由於使用u8類型表示local索引，可能導致整數溢出。雖然Move語言有校驗locals個數的過程，但只檢查了局部變量數量，沒有包括參數長度。

這個整數溢出漏洞可能導致拒絕服務攻擊(DoS)。攻擊者可以構造一個循環代碼塊，利用溢出改變塊的狀態，使新的locals map與之前不同。當再次執行execute_block函數時，如果指令需要訪問的索引在新的AbstractState locals map中不存在，就會導致panic，從而使整個節點崩潰。

爲了演示這個漏洞，我們提供了一個可在git中重現的PoC。這個PoC包含一個帶有無條件分支指令的基本塊，可以多次觸發execute_block和join函數。通過精心設置參數和局部變量數量，可以使新的locals map長度減少到8，然後在第二次執行時觸發panic。

這個漏洞再次證明了沒有絕對安全的代碼。盡管Move語言在執行前進行了嚴格的靜態校驗，但仍可能被溢出漏洞繞過。這也強調了代碼審計的重要性，以及在語言設計中增加運行時安全檢查的必要性。

作爲Move語言安全研究的領導者，我們將繼續深入研究Move的安全問題，並建議語言設計者在Move運行時增加更多的檢查代碼，以防止意外情況發生。目前Move語言主要在verify階段進行安全檢查，但我們認爲這還不夠。一旦驗證被繞過，運行階段缺乏足夠的安全加固可能導致更嚴重的問題。