從安全角度看 Move 語言特性與可能存在的漏洞

發表於 2022-11-26 15:00 作者： Defi之道

圖片來源：由無界版圖AI工具生成

此前，Beosin 宣布了全新升級的安全審計服務，而現在，Beosin 安全團隊正式宣布推出針對 Move 智能合約的安全審計服務，旨在提前發現並協助項目方修復項目中的安全風險，保障用戶與項目方的資產安全。

1、基礎概念

Move 語言最初是由 Facebook 團隊爲 Diem（原名 Libra）區塊鏈而設計开發的一門新語言。而 Libra 的使命是打造一個簡單的全球貨幣和金融基礎設施，爲數十億人提供支持。Move 語言旨在提供一個安全、可編程的基礎，可以在此基礎上構建這一愿景。Move 必須能夠以精確、可理解和可驗證的方式表達 Diem 貨幣和治理規則。從長遠來看，Move 必須能夠對構成金融基礎設施的各種資產和相應的業務邏輯進行編碼。

那么，如何實現這一愿景呢？在 Move 的白皮書中提出了設計時考慮的四個關鍵目標：first-class 資產、靈活性、安全性和可驗證性。其中 first-class 資產是實現這一愿景的基礎。要理解 first-class 資產，我們先來介紹 Move 語言中的幾個比較重要的基礎概念。

1.1 結構體

和其他很多語言一樣，Move 語言中的結構體也是使用 struct 定義。它是自定義類型，也是 Move 中創建自定義類型的唯一方法。結構體可以包含復雜數據，也可以不包含任何數據，但不允許定義遞歸結構體。結構體由字段組成，可以簡單地理解成「key-value」存儲，其中 key 是字段的名稱，而 value 是存儲的內容。

1.2 能力

Move 的類型系統非常靈活，每種類型都可以被四種限制符所修飾。這四種限制符我們稱之爲 abilities，它們的功能分別是：

• Copy - 被修飾的值可以被復制。

• Drop - 被修飾的值在作用域結束時可以被丟棄。

• Key - 被修飾的值可以作爲鍵值對全局狀態進行訪問。

• Store - 被修飾的值可以被存儲到全局狀態。

而 Move 的基本類型缺省具有 store, copy 和 drop 限制，自定義類型缺省情況下結構體不帶任何限制符。

1.3 資源

介紹完了結構體和能力，接下來就是 Move 語言中的核心概念：資源（resource）。

如果定義的結構體（struct）不能復制（copy）也不能丟棄（drop），我們就將它們稱爲資源。默認情況下，結構體是线性和短暫的。它們不能復制，不能丟棄，不能存儲在全局存儲中。這意味着所有值都必須擁有被轉移的所有權，並且值必須在程序執行結束時處理。我們可以通過賦予結構體能力（abilities）來簡化這種行爲，允許值被復制或刪除，以及存儲在全局存儲中或定義全局存儲的模式。

Move 語言中的這個屬性對於現實世界中資源（例如貨幣）的建模非常有用，因爲貨幣在理論上是不希望在流通過程中被復制或丟失的。

1.4 模塊

Move 語言中，代碼都是以模塊（module）的形式進行組織的。如何理解模塊呢？抽象的理解，Move 語言中的模塊（module）/ 資源（resource）/ 方法（function）之間的交互與傳統的面向對象語言中的類（class）/ 對象（object）/ 方法（function）之間的關系非常相似。

而與其他區塊鏈語言相比，Move 中的模塊類似於其他區塊鏈中的智能合約。开發者在模塊中聲明資源類型和方法，這些類型和方法定義了創建、銷毀和更新已聲明資源的規則。

1.5 泛型

Move 因爲是靜態語言，所以爲了保證擴展性，Move 選擇了泛型編程的範式。

以 Aptos 爲例，只要查看你持有的資產是 0x1::coin::CoinStore 這樣的類型，就可以知道該資產是由標准模組 0x1::coin 所定義。比如說 Aptos 的原生幣 AptosCoin 的類型是 0x1::aptos_coin::AptosCoin ，意思是 0x1 帳號之下的 aptos_coin 模塊所定義的 AptosCoin 類型，不過這個類型並沒有賦予 key 能力，所以不能成爲資源，他只提供一個種類，而這個類型可以作爲泛型來使用，像是被 0x1::coin::CoinStore 使用。

那么，0x1::coin::CoinStore 就是 0x1 帳號下 coin 模塊所定義的 CoinStore 類型，記錄地址下某種 coin 的資產狀態。所以你的地址下任何 0x1::coin::CoinStore 的資產都通用相同邏輯、有一樣的行爲，都是定義在 0x1::coin 這個模塊裏。

2. 安全性

2.1 設計安全

Move 在白皮書中明確表示，Move 必須拒絕不滿足關鍵屬性的程序，例如 Resource 安全、類型安全和內存安全。我們如何選擇一個可執行的表示，以確保在區塊鏈上執行的每個程序都滿足這些屬性？兩種可能的方法是：

(a) 使用帶有檢查這些屬性的編譯器的高級編程語言

(b) 使用低級無類型匯編並在運行時執行這些安全檢查。

Move 採取了介於這兩個極端之間的方法。Move 的可執行格式是一種類型化的字節碼，它比匯編高級，但比源語言低。字節碼由字節碼驗證器在鏈上檢查 Resource、類型和內存安全性，然後由字節碼解釋器直接執行。這種選擇允許 Move 提供通常與源語言相關的安全保證，但無需將源編譯器添加到受信任的計算庫或將編譯成本添加到交易執行的關鍵路徑中。

除此之外，Move 在設計時內置了很多安全特性，例如算數溢出、默認可見性導致的權限泄露等等。

2.2 底層安全

2.2.1 資源

在現實社會中，資產有兩個屬性難以用數字表示：

1）稀缺性。必須控制系統中資產發行的數量。必須禁止復制現有資產，而創建新資產是一項特權操作。

2）訪問控制。系統參與者必須能夠使用訪問控制策略保護資產。

因此，Move 引入了資源來表示資產。而在區塊鏈應用中，代幣就是一種資源，資源必須要存儲在账戶下面，且在交易過程中，資產必須要流向一個地方，要么轉移到另一個地址，要么被銷毀，代幣不可被復制或被使用多次或被「懸掛（dangling）」。此處可以把資源的操作類比成 c++ 中的唯一指針。

2.2.2 先字節驗證，後合約執行

Move 在設計時就設計爲一種可執行的字節碼語言，其具有內置的安全算法和字節碼驗證器（Bytecode verifier），可以防止許多常見錯誤。即 Move 中的合約代碼要能被執行，必須先被驗證，這使得合約可以免受編譯器的潛在故障和可能遭遇到的攻擊。Krešimir Klas 在其《Smart Contract Development — Move vs. Rust》中表示：「Move 的顯著特徵是可執行的字節碼表示，爲所有程序提供了資源安全保證。考慮到合約的开放部署模型，這一點至關重要——回想一下，任何合約都必須容忍與不可信代碼進行任意交互。如果源碼級线性可以被可執行級別上不受信任的代碼違反，那么其價值就很有限。」

2.2.3 靜態調用

在區塊鏈中，合約的調用方式可以分爲靜態調用和動態調用。若程序調用必須在運行時才能確定被調用的目標，則稱該調用爲動態調用；反之，在運行前即可確定被調用目標，且在運行時無法變更該目標，則稱該調用爲靜態調用。

Move 採用靜態調用方式。即 Move 實現的合約在部署時，其執行邏輯已經被確定。那么我們可以通過靜態分析字節碼，得到合約所有可能路徑上操作的狀態，在區塊瀏覽器或錢包裏提示給用戶。

因此，錢包提供商可以在錢包設計中，在預執行合約時把合約執行後的狀態變更提示給用戶，讓用戶可以知道這個交易操作了自己的哪些重要資產，以及執行後的結果。如下圖，在 StarMask 中的實現效果：

圖源自 jolestar.eth

3. Move 與 Solidity 的比較

3.1 账戶模型

Solidity：

在大多數以太坊 ERC-20 合約中，每個地址的余額都存儲在一個類型的狀態變量 mapping(address => uint256) 中，該狀態變量存儲在特定智能合約的全局存儲中。其結構如下圖所示：

圖源：https://github.com/move-language/move/tree/main/language/documentation/tutorial

Move：

Move 中，類比 solidity 智能合約的模塊瑟吉歐沒有自己存儲空間的。相反，Move 的「全局存儲」是由地址索引的，每個地址下存儲了 Move 模塊和 Move 資源，而資源存儲是類型到值的映射。其結構如下圖所示：

圖源：https://github.com/move-language/move/tree/main/language/documentation/tutorial

3.2 代碼存儲

Solidity： 

在基於 EVM 的鏈中，所有智能合約都有一個獨特的地址，稱爲「合約擁有地址」。合約账戶與部署者账戶（EOA）存在於在同一級別，代碼 hash 存儲在合約账戶地址中，合約部署後不與部署者地址綁定。

Move：

在基於 MoveVM 的鏈中，代碼存儲在 Account resource 的 code module 裏面。

3.3 安全隔離

Solidity：

智能合約的運行環境是鏈的節點給構造出的沙箱環境，多個合約程序是運行在同一個進程內的不同的虛擬機沙箱。智能合約之間的調用是同一個進程內不同的智能合約虛擬機之間的調用，安全完全依賴於智能合約虛擬機之間的隔離。

Move：

Move 的做法則是通過 MoveVM 讓採用 Move 語言的區塊鏈具備確定性，將合約調用放在同一個虛擬機沙盒中，通過編程語言內部的安全性對智能合約的狀態進行隔離，而非依賴虛擬機進行隔離。

3.4 合約升級

Solidity：

EVM 中合約升級的方法是將合約數據和邏輯分析：代理合約（Proxy）負責轉發交易到邏輯合約，並保存合約數據；邏輯合約（Logic）負責實現功能邏輯。升級時，只需要重新部署新版本的邏輯合約，並將代理合約中的邏輯合約實例指向新版本邏輯合約實例即可。此時，邏輯合約升級並不會影響合約原來已有的數據。 

如下圖，代碼存儲字段指定的是代理能合約被調用時做 delegate call 的合約代碼，合約升級本質上是部署一個新的邏輯合約，並改變 code 字段以重定向 delegate call。

Move：

Move 語言中對於合約升級，其實現是在系統模塊 code.move 中執行升級邏輯，在代碼部署前檢查升級策略和兼容性。在兼容性檢查後，寫在 resource 中的代碼通過一個原生函數調用被替換，並將執行新的邏輯。

圖片截取自：https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-framework/sources/code.move#L132

4. Move 程序可能出現的漏洞點

1） 开發者在使用 Aptos、Sui，或者其他基於 Move 的 blockchain 中獨特的 Framework 進行开發時，應保持一定程度的安全意識，確保供應鏈安全。

2） 函數權限問題。對於一些函數調用的權限要仔細劃分，因爲一些關鍵函數會涉及到治理，嚴重的會影響到資金安全，針對這種函數調用需要對調用者進行鑑權。

3） 業務邏輯在設計和代碼實現時，均需注意其中的邏輯問題。

4） 關於 Move 系項目，在模塊升級時需要注意的點：

• 根據合約升級政策，代碼的所有者對升級權限有完全的控制權。

• 代碼的 owner 在初始部署後是不可改變的。

• 部署者的地址在部署後永遠擁有升級權限。

原文標題：《Beosin | 正式推出針對 Move 智能合約的安全審計服務，從安全角度看 Move 語言（上、下）》

撰文：Beosin

來源：DeFi之道

標題：從安全角度看 Move 語言特性與可能存在的漏洞

地址：https://www.coinsdeep.com/article/7776.html

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