CertiK：Sui最新漏洞“倉鼠輪”，技術細節與深入分析

2023-06-29 16:06:40

此前， CertiK 團隊於 Sui 區塊鏈發現了一系列拒絕服務漏洞。在這些漏洞中，一種新型且具有嚴重影響力的漏洞格外引人注目。該漏洞可導致 Sui 網絡節點無法處理新的交易，效果等同於整個網絡完全關閉。

就在上周一， CertiK 因發現該重大安全漏洞，獲得了 SUI 50 萬美元漏洞賞金。美國業內權威媒體 CoinDesk 對該事件進行了報道，隨後各大媒體也緊隨其報道發布了相關新聞。

該安全漏洞被形象地稱為“倉鼠輪”：其獨特的攻擊方式與目前已知的攻擊不同，攻擊者只需提交一個大約 100 字節的載荷，就能觸發 Sui 驗證節點中的一個無限循環，使其不能響應新的交易。

此外，攻擊帶來的損害在網絡重啓後仍能持續，並且能在 Sui 網絡中自動傳播，讓所有節點如倉鼠在輪上無休止地奔跑一樣無法處理新的交易。因此我們將這種獨特的攻擊類型稱為“倉鼠輪”攻擊。

發現該漏洞後，CertiK 通過 Sui 的漏洞賞金計劃向 Sui 進行了報告。Sui 也第一時間進行了有效回應，確認了該漏洞的嚴重性，並在主網啓動前積極採取了相應措施對問題進行了修復。除了修復此特定的漏洞外，Sui 還實施了預防性的緩解措施，以減少該漏洞可能造成的潛在損害。

為了感謝 CertiK 團隊負責地披露，Sui 向 CertiK 團隊頒發了 50 萬美元獎金。

下文中將從技術層面披露此關鍵漏洞的細節，闡明該漏洞的根本原因和潛在影響。

驗證器在 Sui 中的關鍵作用

如 Sui 和 Aptos 這樣基於 Move 語言的區塊鏈，其防止惡意載荷攻擊的保障機制主要是靜態驗證技術。通過靜態驗證技術，Sui 可在合約發布或升級之前檢查用戶提交的載荷有效性。驗證器提供了一系列檢查器用來確保結構和語義的正確性，只有當通過檢查驗證後，合約才會進入 Move 虛擬機被執行。

Move 鏈上的惡意載荷威脅

Sui 鏈在原始 Move 虛擬機之上提供了一套新的存儲模型與接口，因此 Sui 有一個定制版的 Move 虛擬機。為了支持新的存儲原語，Sui 進一步針對不可信載荷的安全驗證引入了一系列額外的、定制的檢查手段，如對象安全及全局存儲訪問等功能。這些定制檢查手段契合了 Sui 的獨特功能，因此我們將這些定制檢查稱為 Sui 驗證器。

Sui 對載荷的檢查順序

如上圖所示，驗證器中的大多數檢查會針對 CompiledModule（表示用戶提供的合約載荷運行）進行結構層面的安全驗證。例如，通過“重復檢查器”確保運行時載荷中沒有重復的條目；通過“限制檢查器”確保運行時載荷中每個字段的長度都在允許的條目上限之內。

除了結構層面的檢查之外，驗證器的靜態檢查仍需要更復雜的分析手段，以確保不可信載荷在語義層面的強健性。

了解 Move 的抽象解釋器：线性和迭代分析

由 Move 提供的抽象解釋器，是一個專門為通過抽象解釋在字節碼上執行復雜安全分析而設計的框架。這種機制使得驗證過程更加精細和准確，每個驗證者都被允許定義他們獨特的抽象狀態從而進行分析。

在开始運行時，抽象解釋器從編譯的模塊中構建控制流圖（CFG）。這些 CFG 中的每個基本塊都會維護一組狀態，即“前序狀態”和“後序狀態”。“前序狀態”提供了一個基本塊執行前的程序狀態快照，而“後序狀態”則提供了基本塊執行後的程序狀態描述。

當抽象解釋器在控制流圖中沒有遇到回跳（或循環）時，它則遵循一個簡單的线性執行原則：每個基本塊都被依次分析，並根據塊中每個指令的語義計算出前序狀態和後序狀態。其結果就是一個程序在執行過程中每個基本塊級別狀態的精准快照，幫助驗證程序的安全屬性。

Move 抽象解釋器的工作流程

然而，當控制流中存在循環時，這個過程則變得更加復雜。循環的出現意味着控制流圖中包含一條回跳的邊，回跳邊的源頭對應着當前基本塊的後序狀態，而回跳邊的目標基本塊（循環頭部）是一個之前已經分析過的基本塊的前序狀態，因此抽象解釋器需要對回跳相關的兩個基本塊的狀態進行仔細合並。

如果發現合並後狀態與循環頭部基本塊現有的前序狀態不同，抽象解釋器就會更新循環頭部基本塊的狀態，並從這個基本塊开始重新啓動分析。這個迭代分析過程將一直持續到循環預狀態穩定。換句話說，這個過程不斷重復，直到循環頭部基本塊的前序狀態在迭代之間不再變化。達到一個固定點，則表明循環分析已經完成。

Sui IDLeak 驗證器：定制的抽象解釋分析

與原來的 Move 設計不同，Sui 的區塊鏈平臺引入了一個獨特的以“目標”為中心的全局存儲模型。這個模型的一個顯著特點是：任何具有 key 屬性（作為索引上鏈存儲）的數據結構必須以 ID 類型作為該結構的第一個字段。ID 字段不可改變，且不能轉移到其他目標上，因為每個對象必須有一個全局唯一的 ID。為了確保這些特性，Sui 在抽象解釋器上建立了一套自定義分析邏輯。

IDLeak 驗證器，也被稱為 id_leak_verifier，與抽象解釋器協同工作進行分析。它有着自己獨特的 AbstractDomain，被稱為 AbstractState。每個 AbstractState 由多個局部變量對應的 AbstractValue 組成。通過 AbstractValue 來監督每個局部變量的狀態，以此來追蹤一個 ID 變量是否是全新的。

在結構體打包的過程中，IDLeak 驗證器只允許將一個全新的 ID 打包到一個結構體中。通過抽象解釋分析，IDLeak 驗證器可以詳盡地跟蹤本地數據流狀態，以確保沒有現有的 ID 被轉移到其他結構體對象。

Sui IDLeak 驗證器狀態維護不一致問題

IDLeak 驗證器通過實現 AbstractState::join 函數與 Move 抽象解釋器集成。這個函數在狀態管理，特別是在合並和更新狀態值方面中起着不可或缺的作用。

詳細檢查這些函數以了解它們的操作：

在 AbstractState::join 中，該函數將另一個 AbstractState 作為輸入，並試圖將其本地狀態與當前對象的本地狀態合並。對於輸入狀態中的每個局部變量，它將該變量的值與它在局部狀態中的當前值進行比較（如果沒有找到，默認值為 AbstractValue::Other）。如果這兩個值不相等，它將設置一個“changed”的標志，作為最終狀態合並結果是否變化的依據，並通過調用 AbstractValue::join 來更新本地狀態中的本地變量值。

在 AbstractValue::join 中，該函數將其值與另一個 AbstractValue 進行比較。如果它們相等，它將返回傳入的值。如果不相等，則返回 AbstractValue::Other。

然而，這個狀態維護邏輯包含一個隱藏的不一致性問題。盡管 AbstractState::join 會基於新舊值的不同而返回一個表示合並狀態發生變化（JoinResult::Changed）的結果，但合並更新後的狀態值仍然可能是不變的。

這種不一致的問題是由操作順序導致的：在 AbstractState::join 中對改變狀態的判定發生在狀態更新（AbstractValue::join）之前，這種判定並不反映真正的狀態更新結果。

此外，在 AbstractValue::join 中，AbstractValue::Other 對合並的結果起着決定性作用。例如，如果舊值是 AbstractValue::Other，而新值是 AbstractValue::Fresh，則更新的狀態值仍然是 AbstractValue::Other，即便新舊值不同，更新後狀態本身沒有變化。

示例：狀態連接的不連貫性

這就引入了一個不一致：即合並基本塊狀態的結果被判定為“改變”，但合並後的狀態值本身並沒有發生變化。在抽象解釋分析的過程中，出現這種不一致問題有可能產生嚴重的後果。我們回顧抽象解釋器在控制流圖（CFG）中出現循環時的行為：

當遇到一個循環時，抽象解釋器採用一種迭代的分析方法來合並回跳目標基本塊和當前基本塊的狀態。如果合並後的狀態發生變化，抽象解釋器則會從跳轉目標开始重新分析。

然而，如果抽象解釋分析的合並操作錯誤地將狀態合並結果標記為“變化”，而實際上狀態內部變量的值沒有發生變化，就會導致無休止的重新分析，產生無限循環。

進一步利用不一致在 Sui IDLeak 驗證器中觸發無限循環

利用這種不一致性，攻擊者可以構造一個惡意的控制流圖，誘使 IDLeak 驗證器進入一個無限循環。這個精心構造的控制流圖由三個基本塊組成：BB 1 和 BB 2 ，BB 3 。值得注意的是，我們有意引入了一條從 BB 3 到 BB 2 的回跳邊來構造一個循環。

惡意 CFG+狀態，可導致 IDLeak 驗證器內部死循環

這個過程從 BB 2 开始，其中一個特定局部變量的 AbstractValue 被設置為::Other。在執行 BB 2 之後，流程轉移到 BB 3 ，在那裏同一變量被設置為::Fresh。在 BB 3 的結尾處，有一條回跳邊，跳轉到 BB 2 。

在抽象解釋分析這個例子的過程中，前文提到的不一致性起到了關鍵作用。當回跳邊被處理時，抽象解釋器試圖將 BB 3 的後序狀態（變量為“::Fresh”）與 BB 2 的前序狀態（變量為“::Other”）連接起來。AbstractState::join 函數注意到了這個新舊值不同的差異並設置了“變化”的標志，以此表示需要對 BB 2 的進行重新分析。

然而，AbstractValue::join 中 “::Other”的主導行為意味着 AbstractValue 合並後，BB 2 狀態變量的實際值仍然是“::Other”，狀態合並的結果並沒有發生變化。

因此這個循環過程一旦开始，即當驗證器繼續重新分析 BB 2 以及它的所有後繼基本塊節點（本例中為 BB 3），它就會無限期地持續下去。無限循環消耗了所有可用的 CPU 周期，使其無法處理響應新的交易，這種情況在驗證器重新啓動後仍然存在。

通過利用這個漏洞，驗證節點如倉鼠在輪上無休止地奔跑一樣無限循環，無法處理新的交易。因此我們將這種獨特的攻擊類型稱為“倉鼠輪”攻擊。

“倉鼠輪”攻擊可以有效地使 Sui 驗證器陷入停頓，進而導致整個 Sui 網絡癱瘓。

理解了漏洞成因與觸發過程之後，我們通過使用以下 Move 字節碼模擬構建了一個具體例子，成功地在真實環境中的模擬中觸發了該漏洞：

這個例子通過精心構造的字節碼，展示了如何在真實環境中觸發漏洞。具體來說，攻擊者可以在 IDLeak 驗證器中觸發一個無限循環，利用僅僅約 100 字節的載荷即可消耗 Sui 節點的所有 CPU 周期，有效阻止新交易處理，並導致 Sui 網絡拒絕服務。

“倉鼠輪”攻擊在 Sui 網絡中的持續性危害

Sui 的漏洞賞金計劃對漏洞等級的評定有着嚴格的規定，主要依據對整個網絡的危害程度進行評定。滿足“嚴重（critical）”評級的漏洞必須使整個網絡關停並有效阻礙新交易確認，同時需要硬分叉來修復問題；如果漏洞只能使部分網絡節點拒絕服務，至多被評定為 “中危（medium）”或“高危（high）”漏洞。

CertiK Skyfall 團隊發現的“倉鼠輪”漏洞可以使整個 Sui 網絡關停，同時需要官方發布新版本進行升級修復。基於對該漏洞的危害程度，Sui 最終被將其評定為“嚴重”等級。為了進一步理解“倉鼠輪”攻擊造成的嚴重性影響原因，我們有必要了解 Sui 後端系統的復雜架構，特別是鏈上交易發布或升級的整個過程。

在 Sui 中提交交易的交互概述

最初，用戶交易通過前端 RPC 提交，經基本驗證後傳遞到後端服務。Sui 後端服務負責進一步驗證傳入的交易載荷。在成功驗證了用戶的籤名後，交易被轉化為交易證書（包含交易信息以及 Sui 的籤名）。

這些交易證書是 Sui 網絡運作的基本組成部分，可以在在網絡中的各個驗證節點之間傳播。對於合約創建/升級交易，在其可以上鏈之前，驗證節點會調用 Sui 驗證器檢查並驗證這些證書的合約結構/語義的有效性。正是在這個關鍵的驗證階段，“死循環”漏洞可以被觸發利用。

當該漏洞被觸發時，它會導致驗證過程無限期中斷，有效阻礙系統處理新交易的能力，並導致網絡完全關閉。雪上加霜的是，節點重啓後該情況仍然存在，這也就意味着傳統的緩解措施遠遠不夠。該漏洞一旦被觸發，則會出現“持續破壞”的情況從而對整個 Sui 網絡留下持久影響。

Sui 的解決方法

經過 CertiK 反饋後，Sui 及時確認了該漏洞，並發布了一個修復程序來解決該關鍵缺陷。該修復程序確保了狀態改變和改變後標志之間的一致性，消除了“倉鼠輪”攻擊造成的關鍵影響。

為了消除上述的不一致，Sui 的修復包括對 AbstractState::join 函數的一個微小但關鍵的調整。這個補丁移除了在執行 AbstractValue::join 之前判定狀態合並結果的邏輯，取而代之的是首先執行 AbstractValue::join 函數進行狀態合並，通過比較最終更新結果和原始狀態值（old_value）來設置合並是否發生變化的標記。

這樣一來，狀態合並的結果與真實更新的結果將保持一致，分析過程中不會發生死循環。

除了修復這個特定的漏洞外，Sui 還部署了緩解措施，以減少未來驗證器漏洞的影響。根據 Sui 在 bug 報告中的回復，緩解措施涉及一個叫做 Denylist 的功能。

然而，驗證器有一個節點配置文件，允許他們暫時拒絕某些類別的交易。這個配置可以用來暫時禁止處理發布和軟件包升級。由於這個 bug 是在籤署發布或軟件包升級 tx 之前運行 Sui 驗證器時發生的，而拒絕列表將停止驗證器的運行並將惡意 tx 丟棄，暫時拒絕列表這些 tx 類型是一個 100% 有效的緩解措施（盡管它將暫時中斷試圖發布或升級代碼的人的服務）。

順便提一下，我們有這個 TX 拒絕列表配置文件已經有一段時間了，但我們也為證書添加了一個類似的機制，作為你之前報告的 “驗證器死循環 ”漏洞的後續緩解手段。有了這個機制，我們將對這種攻擊有更大的靈活性：我們將使用證書拒絕名單配置來使驗證器忘記壞的證書（打破死循環），並使用 TX 拒絕名單配置來禁止發布/升級，從而防止創建新的惡意攻擊交易。謝謝你讓我們思考這個問題！

驗證器在籤署交易之前有有限的 "ticks"（與 gas 不同）用於字節碼驗證，如果在交易中發布的所有字節碼不能在這么多 ticks 中得到驗證，驗證器將拒絕籤署該交易，防止它在網絡上執行。以前，計量只適用於一組選定的復雜驗證器通過。為了應對這個問題，我們將計量擴展到每個驗證器，以保證驗證器在每個 tick 的驗證過程中所執行的工作有一個約束。我們還修復了 ID 泄漏驗證器中的潛在無限循環錯誤。

——來自 Sui 开發者關於漏洞修復的說明

總而言之，Denylist 使驗證者能夠通過禁用發布或升級流程來暫時規避針對驗證器中的漏洞利用並有效地防止一些惡意交易帶來的的潛在破壞。當 Denylist 的緩解措施生效時，節點通過犧牲自身的發布/更新合約功能，來確保自己能夠繼續工作。