此前，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為修復這一關鍵問題所做的及時反應，並分享了漏洞修復以及後續同類漏洞緩解的方法。
