此前，CertiK 團隊於Sui 區塊鏈發現了一系列拒絕服務漏洞。在這些漏洞中，一種新型且具有嚴重影響力的漏洞格外引人注目。該漏洞可導致Sui 網絡節點無法處理新的交易，效果等同於整個網絡完全關閉。
就在上週一，CertiK 因發現該重大安全漏洞，獲得了SUI 50 萬美元漏洞賞金。美國業內權威媒體CoinDesk 對該事件進行了報導，隨後各大媒體也緊隨其報導發布了相關新聞。
該安全漏洞被形像地稱為“倉鼠輪”：其獨特的攻擊方式與目前已知的攻擊不同，攻擊者只需提交一個大約100 字節的載荷，就能觸發Sui 驗證節點中的一個無限循環，使其不能響應新的交易。
此外，攻擊帶來的損害在網絡重啟後仍能持續，並且能在Sui 網絡中自動傳播，讓所有節點如倉鼠在輪上無休止地奔跑一樣無法處理新的交易。因此我們將這種獨特的攻擊類型稱為“倉鼠輪”攻擊。
發現該漏洞後，CertiK 通過Sui 的漏洞賞金計劃向Sui 進行了報告。 Sui 也第一時間進行了有效回應，確認了該漏洞的嚴重性，並在主網啟動前積極採取了相應措施對問題進行了修復。除了修復此特定的漏洞外，Sui 還實施了預防性的緩解措施，以減少該漏洞可能造成的潛在損害。
一級標題
一級標題
圖片描述
圖片描述
圖片描述
圖片描述
Sui 對載荷的檢查順序
一級標題
一級標題
了解Move 的抽象解釋器：線性和迭代分析
由Move 提供的抽象解釋器，是一個專門為通過抽象解釋在字節碼上執行複雜安全分析而設計的框架。這種機制使得驗證過程更加精細和準確，每個驗證者都被允許定義他們獨特的抽象狀態從而進行分析。
圖片描述
圖片描述
Move 抽象解釋器的工作流程
一級標題
一級標題
Sui IDLeak 驗證器：定制的抽象解釋分析
與原來的Move 設計不同，Sui 的區塊鏈平台引入了一個獨特的以“目標”為中心的全局存儲模型。這個模型的一個顯著特點是：任何具有key 屬性（作為索引上鍊存儲）的數據結構必須以ID 類型作為該結構的第一個字段。 ID 字段不可改變，且不能轉移到其他目標上，因為每個對象必須有一個全局唯一的ID。為了確保這些特性，Sui 在抽象解釋器上建立了一套自定義分析邏輯。
一級標題
一級標題
Sui IDLeak 驗證器狀態維護不一致問題
IDLeak 驗證器通過實現AbstractState::join 函數與Move 抽象解釋器集成。這個函數在狀態管理，特別是在合併和更新狀態值方面中起著不可或缺的作用。
詳細檢查這些函數以了解它們的操作：
在AbstractState::join 中，該函數將另一個AbstractState 作為輸入，並試圖將其本地狀態與當前對象的本地狀態合併。對於輸入狀態中的每個局部變量，它將該變量的值與它在局部狀態中的當前值進行比較（如果沒有找到，默認值為AbstractValue::Other）。如果這兩個值不相等，它將設置一個“changed”的標誌，作為最終狀態合併結果是否變化的依據，並通過調用AbstractValue::join 來更新本地狀態中的本地變量值。
在AbstractValue::join 中，該函數將其值與另一個AbstractValue 進行比較。如果它們相等，它將返回傳入的值。如果不相等，則返回AbstractValue::Other。
然而，這個狀態維護邏輯包含一個隱藏的不一致性問題。儘管AbstractState::join 會基於新舊值的不同而返回一個表示合併狀態發生變化（JoinResult::Changed）的結果，但合併更新後的狀態值仍然可能是不變的。
圖片描述
圖片描述
示例：狀態連接的不連貫性
這就引入了一個不一致：即合併基本塊狀態的結果被判定為“改變”，但合併後的狀態值本身並沒有發生變化。在抽象解釋分析的過程中，出現這種不一致問題有可能產生嚴重的後果。我們回顧抽象解釋器在控制流圖（CFG）中出現循環時的行為：
一級標題
一級標題
圖片描述
圖片描述
惡意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 網絡癱瘓。
一級標題
一級標題
“倉鼠輪”攻擊在Sui 網絡中的持續性危害
圖片描述
圖片描述
在Sui 中提交交易的交互概述
最初，用戶交易通過前端RPC 提交，經基本驗證後傳遞到後端服務。 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 洩漏驗證器中的潛在無限循環錯誤。
總結
總結
總結
本文我們分享了由CertiK Skyfall 團隊發現的“倉鼠輪”攻擊技術細節，解釋了這種新型攻擊是如何利用關鍵漏洞來導致Sui 網絡完全關閉的。此外，我們也仔細研究了Sui 為修復這一關鍵問題所做的及時反應，並分享了漏洞修復以及後續同類漏洞緩解的方法。
