Move语言又一高危漏洞深度剖析

之前我们发现了Aptos Moveevm的一个严重漏洞,经过深入研究,我们又发现了一个新的整数溢出漏洞。这次漏洞的触发过程更加有趣,下面我们将深入分析这个漏洞,同时介绍一些Move语言的背景知识。相信通过本文的讲解,你会对Move语言有更深入的理解。

众所周知,Move语言在执行字节码之前会验证代码单元。验证过程分为4个步骤,而这个漏洞就出现在reference_safety步骤中。

reference_safety模块定义了用于验证过程主体的引用安全性的转移函数。其检查包括验证没有悬空引用、对可变引用的访问是否安全、对全局存储引用的访问是否安全等。

引用安全验证的入口函数会调用analyze_function。在analyze_function中,函数会对每一个基本块进行验证。基本块是指除了入口和出口之外没有分支指令的代码序列。

Move语言通过遍历字节码、查找所有分支指令以及循环指令序列来确定基本块。一个典型的Move IR代码基本块示例可能包含3个基本块,分别由BrTrue、Branch和Ret指令确定。

Move中的引用安全

借鉴Rust语言的思想,Move支持两种类型的引用:不可变引用(&)和可变引用(&mut)。不可变引用用于从结构中读取数据,可变引用用于修改数据。合理使用引用类型有助于维护安全性并识别读取模块。

Move的引用安全模块会以函数为单位,扫描函数中基本块的字节码指令,验证所有引用操作是否合法。验证过程主要涉及AbstractState结构体,它包含borrow graph和locals,用于确保函数中引用的安全性。

验证过程会比较执行基本块前后的state,并将结果合并以更新块状态,同时将该块的后置条件传播到后续块。这个过程类似于V8 turbofan中的Sea of Nodes思想。

主循环会执行块代码,然后尝试合并pre state和post state。如果状态发生变化且当前块存在指向自身的后向边(表示有循环),则会跳回循环开头,继续执行此基本块,直到post state等于pre state或因错误而中止。

漏洞分析

漏洞出现在判断join结果是否改变的过程中。join_函数用于更新本地变量和borrow关系图。当函数参数长度加上局部变量长度超过256时,由于local变量是u8类型,在遍历locals时会发生溢出。

虽然Move有校验locals个数的过程,但在check bounds模块只校验了locals,并未包括参数length。开发人员似乎意识到需要检查参数和本地值的总和,但代码实际上只校验了本地变量的数量。

从整型溢出到DoS攻击

主循环会扫描代码块并调用execute_block函数,之后合并执行前后的state。当代码中存在循环时,会跳转到代码块开始再次执行。

如果我们构造一个循环代码块并利用溢出改变块的state,使新的locals map与之前不同,那么再次执行execute_block时,分析basic block中的指令序列会访问新的locals map。此时如果指令需要访问的索引在新的map中不存在,就会导致DoS。

在reference safety模块中,MoveLoc/CopyLoc/FreeRef操作码可以实现这个目标。以copy_loc函数为例,它会尝试通过LocalIndex获取本地值,如果LocalIndex不存在则会导致panic,从而使整个节点崩溃。

PoC演示

我们可以构造一个包含无条件分支指令的basic block,使其多次调用execute_block和join函数。通过设置适当的参数和本地变量数量,可以在第一次执行后将新的locals map长度缩减为8。

在第二次执行时,尝试访问不存在的offset就会导致panic,从而触发DoS。

总结

这个漏洞说明即使是经过严格静态校验的Move语言也存在安全隐患。溢出漏洞可以绕过边界校验,突显了代码审计的重要性。

作为Move语言安全研究的领导者,我们建议语言设计者在Move运行时增加更多检查代码,以防止意外情况发生。目前Move主要在verify阶段进行安全检查,但运行阶段缺乏足够的安全加固,可能会导致更严重的问题。

我们还发现了Move语言的另一个漏洞,将在后续与大家分享。