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

此前，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基金會向11個生態項目提供98.6萬美元贈款:6月16日消息，Sui基金會已向11個基于Sui的項目授予98.6萬美元的獎勵，受贈項目包括Web3數據基礎設施公司BlockVision（構建了瀏覽器SuiVision）、游戲化體驗工具提供方HolaSui、KSui（為客戶端與Sui全節點交互提供Kotlin Multiplatform庫）、LotusGalaxy（專注于NFT和NFT工具）、TheMove Dev（正在開發一系列開源API和工具）、Orange Comet、Pyth Network、Sentio、NFT平臺Somis.xyz、社交應用Suia、SuiAnalytics。[2023/6/16 21:40:52]

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

Sui對載荷的檢查順序

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

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

了解Move的抽象解釋器：

線性和迭代分析

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

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

OKX：目前SUI撤單問題已全部恢復，提幣已開放:5月4日消息，歐易OKX發推文稱，目前SUI撤單問題已經全部恢復，提幣已開放。所有受影響的用戶均可正常操作，關于受損用戶的數據核對也基本完成，稍后將會公布詳細的補償方案。[2023/5/4 14:42:09]

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

Move 抽象解釋器的工作流程

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

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

Sui IDLeak驗證器：

定制的抽象解釋分析

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

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

Sui基金會與Immunefi合作開展Bug Bounty賞金計劃:4月21日消息，Sui基金會宣布與Immunefi合作開展BugBounty賞金計劃，旨在激勵白帽黑客發現有效的漏洞與問題，從而幫助維護平臺的安全與穩定。

漏洞影響范圍分為低級、中級、高級、最高級四個等級，提交所有的漏洞報告時，必須附帶相關證明，說明該漏洞是在運行測試網還是主網時發現，以及最終影響的資產范圍。滿足這些條件才能被視為有效并參與獎勵瓜分。[2023/4/21 14:17:23]

在結構體打包的過程中，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）的結果，但合并更新后的狀態值仍然可能是不變的。

Sui已上線Sui Testnet Wave2，將測試Sui代幣經濟學:1月26日消息，Sui Network已上線Sui Testnet Wave2，該測試網將專注于測試Sui網絡的epoch管理、代幣經濟學和權益質押等等，允許構建者在測試網上發布、測試和共享他們的應用程序，任何人都可以運行完整節點。

據悉，Wave2將通過兩款測試游戲Frenemies和Validator Game測試其代幣經濟學的Epoch管理和Gas機制。[2023/1/26 11:30:30]

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

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

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

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

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

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

進一步利用不一致

在Sui IDLeak驗證器中觸發無限循環

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

Sui基金會宣布將發布初始代幣分配等信息:據官方消息，Sui基金會現已啟動，除了贈款計劃，Sui基金會將發布更多關于Sui初始代幣分配、獲得Sui基金會質押委托的流程以及社區成員獲得資金的其他途徑。

接下來幾周，Sui基金會將分享更多信息并宣布與去中心化和社區建設使命相關的未來計劃。目前，Sui基金會正在設計一些新內容，包括傳播Sui知識的教育和社區計劃、研究計劃以改進Sui的技術以及Validator和Move計劃以增強Sui基礎設施的采用。

據此前報道，10月25日，Sui基金會網站已上線，并開放開發者Grant申請入口。[2022/10/28 11:51:46]

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

CertiK中文社區

企業專欄

閱讀更多

金色早8點

Odaily星球日報

金色財經

Block unicorn

DAOrayaki

曼昆區塊鏈法律

Tags：SUIBSTTRACRACMulti Wallet SuiteBSTZTrace Network Labseternalcontract

火星幣