此前，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驗證器進入一個無限循環。這個精心構造的控制流圖由三個基本塊組成：BB1和BB2，BB3。值得注意的是，我們有意引入了一條從BB3到BB2的回跳邊來構造一個循環。

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

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

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

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

因此這個循環過程一旦开始，即當驗證器繼續重新分析BB2以及它的所有後繼基本塊節點（本例中爲BB3），它就會無限期地持續下去。無限循環消耗了所有可用的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的緩解措施生效時，節點通過犧牲自身的發布/更新合約功能，來確保自己能夠繼續工作。

總結

本文我們分享了由CertiK Skyfall團隊發現的“倉鼠輪”攻擊技術細節，解釋了這種新型攻擊是如何利用關鍵漏洞來導致Sui網絡完全關閉的。此外，我們也仔細研究了Sui爲修復這一關鍵問題所做的及時反應，並分享了漏洞修復以及後續同類漏洞緩解的方法。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。