CertiK 的Skyfall 團隊最近在Aptos、StarCoin 和Sui 等多個區塊鏈中發現了基於Rust 的RPC 節點的多個漏洞。由於RPC 節點是連接dApp 和底層區塊鏈的關鍵基礎設施組件，其穩健性對於無縫操作至關重要。區塊鏈設計者都知道穩定RPC 服務的重要性，因此他們採用Rust 等內存安全語言來規避可能破壞RPC 節點的常見漏洞。
採用內存安全語言（如Rust）有助於RPC 節點避免許多基於內存破壞漏洞的攻擊。然而，通過最近的審計，我們發現即使是內存安全的Rust 實現，如果沒有經過精心設計和審查，也很容易受到某些安全威脅的影響，從而破壞RPC 服務的可用性。
本文我們將通過實際案例介紹我們對一系列漏洞的發現。
區塊鏈RPC 節點作用
區塊鏈RPC 節點作用
區塊鏈的遠程過程調用（RPC）服務是Layer 1 區塊鏈的核心基礎設施組件。它為用戶提供重要的API 前端，並作為通向後端區塊鍊網絡的網關。然而，區塊鏈RPC 服務與傳統的RPC 服務不同，它方便用戶交互無需身份驗證。服務的持續可用性至關重要，任何服務中斷都會嚴重影響底層區塊鏈的可用性。
審計角度：傳統RPC 服務器VS 區塊鏈RPC 服務器
對傳統RPC 服務器的審計主要集中在輸入驗證、授權/ 認證、跨站請求偽造/ 服務器端請求偽造（CSRF/SSRF）、注入漏洞（如SQL 注入、命令注入）和信息洩露等方面進檢查。
然而，區塊鏈RPC 服務器的情況有所不同。只要交易是簽名的，就不需要在RPC 層對發起請求的客戶端進行身份驗證。作為區塊鏈的前端，RPC 服務的一個主要目標是保證其可用性。如果它失效，用戶就無法與區塊鏈交互，從而阻礙查詢鏈上數據、提交交易或發布合約功能。
因此，區塊鏈RPC 服務器最脆弱的方面是「可用性」。如果服務器宕機，用戶就失去了與區塊鏈交互的能力。更嚴重的是，一些攻擊會在鏈上擴散，影響大量節點，甚至導致整個網絡癱瘓。
為何新區塊鏈會採用內存安全的RPC
一些著名的Layer 1 區塊鏈，如Aptos 和Sui，使用內存安全編程語言Rust 實現其RPC 服務。得益於其強大的安全性和編譯時嚴格的檢查，Rust 幾乎可以使程序免受內存破壞漏洞的影響，如堆棧溢出、和空指針解引用和釋放後重引用等漏洞。
為了進一步確保代碼庫的安全，開發人員需嚴格遵循最佳實踐，例如不引入不安全代碼。在源代碼中使用#![forbid(unsafe_code)]確保阻攔過濾不安全的代碼。
區塊鏈開發者執行Rust 編程實踐的例子
為了防止整數溢出，開發人員通常使用checked_add、checked_sub、saturating_add、saturating_sub 等函數，而不是簡單的加法和減法（+、-）。通過設置適當的超時、請求大小限制和請求項數限制來緩解資源耗盡。
Layer 1 區塊鏈中內存安全RPC 威脅
儘管不存在傳統意義上內存不安全的漏洞，但RPC 節點會暴露在攻擊者容易操縱的輸入中。在內存安全RPC 實現中，有幾種情況會導致拒絕服務。例如，內存放大可能會耗盡服務的內存，而邏輯問題可能會引入無限循環。此外，競態條件也可能構成威脅，並發操作可能會出現意外的事件序列，從而使系統處於未定義的狀態。此外，管理不當的依賴關係和第三方庫可能會給系統帶來未知漏洞。
在這篇文章中，我們的目的是讓人們關注可以觸發Rust 運行時保護的更直接的方式，從而導致服務自行中止。
顯式的Rust Panic:一種直接終止RPC 服務的方法
開發人員可以有意或無意地引入顯式panic 代碼。這些代碼主要用於處理意外或異常情況。一些常見的例子包括：
assert!()：當必須滿足一個條件時使用該macro。如果斷言的條件失敗，程序將panic，表明代碼中存在嚴重錯誤。
panic!()：當程序遇到無法恢復的錯誤且無法繼續執行時調用該函數。
unreachable!()：當一段代碼不應該被執行時使用該macro。如果該macro 被調用，則表示存在嚴重的邏輯錯誤。
unimplemented!() 和todo!()：這些宏是尚未實現功能的佔位符。如果達到該值，程序將崩潰。
unwrap()：該方法用於Option 或Result 類型，當遇到Err 變量或None 時會導致程序宕機。
漏洞一：觸發Move Verifier 中的assert!
Aptos 區塊鏈採用Move 字節碼驗證器，通過對字節碼的抽象解釋進行引用安全分析。execute() 函數是TransferFunctions trait 實現的一部分，模擬基本塊中字節碼指令的執行。
函數execute_inner() 的任務是解釋當前字節碼指令並相應地更新狀態。如果我們已經執行到基本塊中的最後一條指令，如index == last_index 所示，函數將調用assert!(self.stack.is_empty()) 以確保棧為空。此行為背後的意圖是保證所有操作都是平衡的，這也意味著每次入棧都有相應的出棧。
在正常的執行流程中，棧在抽象解釋過程中始終是平衡的。堆棧平衡檢查器（Stack Balance Checker）保證了這一點，它在解釋之前對字節碼進行了驗證。然而，一旦我們將視角擴展到抽象解釋器的範圍，就會發現堆棧平衡假設並不總是有效的。
AbstractInterpreter 中analyze_function 漏洞的補丁程序
抽象解釋器的核心是在基本塊級別中模擬字節碼。在其最初的實現中，在execute_block 過程中，遇到錯誤會提示分析過程記錄錯誤，並繼續執行控制流圖中的下一個塊。這可能會造成一種情況：執行塊中的錯誤會導致堆棧不平衡。如果在這種情況下繼續執行，就會在堆棧不為空的情況下進行assert!檢查，從而引發panic。
這就使得攻擊者有機可趁。攻擊者可通過在execute_block() 中設計特定的字節碼來觸發錯誤，隨後execute() 有可能在堆棧不為空的情況下執行assert，從而導致assert 檢查失敗。這將進一步導致panic 並終止RPC 服務，從而影響其可用性。
為防止出現這種情況，已實施的修復中，確保了在execute_block 函數首次出現錯誤時會停止整個分析過程，進而避免了因錯誤導致堆棧不平衡而繼續分析時可能發生的後續崩潰風險。這一修改消除了可能引起panic 的情況，並有助於提高抽象解釋器的健壯性和安全性。
漏洞二：觸發StarCoin 中的panic！
Starcoin 區塊鏈有自己的Move 實現分叉。在這個Move repo 中，Struct 類型的構造函數中存在一個panic! 如果提供的StructDefinition 擁有Native 字段信息，就會顯式觸發這個panic！。
規範化例程中初始化結構體的顯式panic
這種潛在風險存在於重新發布模塊的過程中。如果被發布的模塊已經存在於數據存儲中，則需要對現有模塊和攻擊者控制的輸入模塊進行模塊規範化處理。在這個過程中，「normalized::Module::new」函數會從攻擊者控制的輸入模塊中構建模塊結構，從而觸發「panic!」。
規範化例程的前提條件
通過從客戶端提交特製的有效載荷，可以觸發該panic。因此，惡意行為者可以破壞RPC 服務的可用性。
結構初始化panic 補丁
Starcoin 的補丁引入了一個新的行為來處理Native 情況。現在，它不會引起panic，而是返回一個空的ec。這減少了用戶提交數據引起panic 的可能性。
隱式Rust Panic: 一種容易被忽視的終止RPC 服務的方法
顯式panic 在源代碼中很容易識別，而隱式panic 則更可能被開發人員忽略。隱式panic 通常發生在使用標准或第三方庫提供的API 時。開發人員需要徹底閱讀和理解API 文檔，否則他們的Rust 程序可能會意外停止。
BTreeMap 中的隱式panic
讓我們以Rust STD 中的BTreeMap 為例。BTreeMap 是一種常用的數據結構，它以排序的二叉樹形式組織鍵值對。BTreeMap 提供了兩種通過鍵值檢索值的方法：get(&self, key: &Q) 和index(&self, key: &Q)。
方法get(&self, key: &Q) 使用鍵檢索值並返回一個Option。Option 可以是Some(&V)，如果key 存在，則返回值的引用，如果在BTreeMap 中沒有找到key，則返回None。
另一方面，index(&self, key: &Q) 直接返回鍵對應的值的引用。然而，它有一個很大的風險：如果鍵不存在於BTreeMap 中，它會觸發隱式panic。如果處理不當，程序可能會意外崩潰，從而成為一個潛在漏洞。
事實上，index(&self, key: &Q) 方法是std::ops::Index trait 的底層實現。該特質為不可變上下文中的索引操作（即container[index]）提供了方便的語法糖。開發者可以直接使用btree_map[key]，調用index(&self, key: &Q) 方法。然而，他們可能會忽略這樣一個事實：如果找不到key，這種用法可能會觸發panic，從而對程序的穩定性造成隱性威脅。
漏洞三：在Sui RPC 中觸發隱式panic
Sui 模塊發布例程允許用戶通過RPC 提交模塊有效載荷。在將請求轉發給後端驗證網絡進行字節碼驗證之前，RPC 處理程序使用SuiCommand::Publish 函數直接反彙編接收到的模塊。
在這個反彙編過程中，提交模塊中的code_unit 部分被用來構建一個VMControlFlowGraph。該構建過程包括創建基本塊，這些塊存儲在一個名為「blocks」的BTreeMap 中。該過程包括創建和操作該Map，在某些條件下，隱式panic 會在這裡觸發。
下面是一段簡化的代碼：
創建VMControlFlowGraph 時的隱式panic
在該代碼中，通過遍歷代碼並為每個代碼單元創建一個新的基本塊來創建一個新的VMControlFlowGraph。基本塊存儲在一個名為block 的BTreeMap 中。
在對堆棧進行迭代的循環中，使用block[&block]對塊圖進行索引，堆棧已經用ENTRY_BLOCK_ID 進行了初始化。這裡的假設是，在block 映射中至少存在一個ENTRY_BLOCK_ID。
然而，這一假設並不總是成立的。例如，如果提交的代碼是空的，那麼在「創建基本塊」過程之後，「塊映射」仍然是空的。當代碼稍後嘗試使用&blocks[&block].successors 中的for succ 遍歷塊映射時，如果未找到key，可能會引起隱式panic。這是因為blocks[&block]表達式本質上是對index() 方法的調用，如前所述，如果鍵不存在於BTreeMap 中，index() 方法將導致panic。
擁有遠程訪問權限的攻擊者可以通過提交帶有空code_unit 字段的畸形模塊有效載荷來利用該函數的漏洞。這個簡單的RPC 請求會導致整個JSON-RPC 進程崩潰。如果攻擊者以最小的代價持續發送此類畸形有效載荷，就會導致服務持續中斷。在區塊鍊網絡中，這意味著網絡可能無法確認新的交易，從而導致拒絕服務（DoS）情況。網絡功能和用戶對系統的信任將受到嚴重影響。
Sui 的修復：從RPC 發布例程中移除反彙編功能
值得注意的是，Move Bytecode Verifier 中的CodeUnitVerifier 負責確保code_unit 部分絕不為空。然而，操作順序使RPC 處理程序暴露於潛在的漏洞中。這是因為驗證過程是在Validator 節點上進行的，而該節點是在RPC 處理輸入模塊之後的一個階段。
針對這一問題，Sui 通過移除模塊發布RPC 例程中的反彙編功能來解決該漏洞。這是防止RPC 服務處理潛在危險、未經驗證的字節碼的有效方法。
此外，值得注意的是，與對象查詢相關的其他RPC 方法也包含反彙編功能，但它們不容易受到使用空代碼單元的攻擊。這是因為它們總是在查詢和反彙編現有的已發布模塊。已發布的模塊必須已經過驗證，因此，在構建VMControlFlowGraph 時，非空代碼單元的假設始終成立。
對開發人員的建議
在了解了顯式和隱式panic 對區塊鏈中RPC 服務穩定性的威脅後，開發人員必須掌握預防或降低這些風險的策略。這些策略可以降低服務意外中斷的可能性，提高系統的彈性。因此CertiK 的專家團隊提出以下建議，並作為Rust 編程的最佳實踐為大家列出。
Rust Panic Abstraction: 盡可能考慮使用Rust 的catch_unwind 函數來捕獲panic，並將其轉換為錯誤信息。這可以防止整個程序崩潰，並允許開發人員以可控的方式處理錯誤。
謹慎使用API：隱式panic 通常是由於濫用標准或第三方庫提供的API 而發生的。因此，充分理解API 並學會適當處理潛在錯誤至關重要。開發人員要始終假設API 可能會失效，並為這種情況做好準備。
適當的錯誤處理：使用Result 和Option 類型進行錯誤處理，而非求助於panic。前者提供了一種更可控的方式來處理錯誤和特殊情況。
添加文檔和註釋：確保代碼文檔齊全，並在關鍵部分（包括可能發生panic 的部分）添加註釋。這將幫助其他開發人員了解潛在風險並有效處理。
總結
基於Rust 的RPC 節點在Aptos、StarCoin 和Sui 等區塊鏈系統中扮演著重要的角色。由於它們用於連接DApp 和底層區塊鏈，因此它們的可靠性對於區塊鏈系統的平穩運行至關重要。儘管這些系統使用的是內存安全語言Rust，但仍然存在設計不當的風險。CertiK 的研究團隊通過現實世界中的例子探討了這些風險，也足以證明了內存安全編程中需要謹慎和細緻的設計。
