Move Language Reproduces Integer Overflow Vulnerability

Recently, a serious integer overflow vulnerability has been discovered in the Move language. This vulnerability occurs during the reference security validation step and may lead to denial of service attacks. By analyzing this vulnerability in depth, we can gain a deeper understanding of the Move language.

The Move language performs code verification before executing bytecode, which consists of four steps. This vulnerability arises in the reference_safety step. The reference_safety module is responsible for verifying the legality of reference operations, including checking for dangling references and whether mutable reference access is safe.

The verification process is conducted on a per-function basis. For each function, the basic blocks within it are first identified. A basic block is a sequence of consecutive code that may only have branches at the entry and exit points. Then, each basic block is analyzed to generate the state before and after execution, and the state is propagated to subsequent blocks.

The status includes two parts of information: locals and borrow graph. Locals record information about local variables, while the borrow graph represents the reference relationships between variables. The analysis process will continuously update this state information.

The vulnerability occurs during the state merging process. When the total number of function parameters and local variables exceeds 256, an integer overflow can occur due to using the u8 type to represent the index. This leads to erroneous merged state information, which may trigger a denial of service attack.

Although the Move language has a mechanism to check the number of local variables, it does not consider the number of parameters. This oversight has led to the emergence of vulnerabilities.

To trigger this vulnerability, an attacker can construct a looping code block that uses overflow to change the state of the block. When executed again, due to incorrect state information, accessing a non-existent variable will cause the program to crash.

This vulnerability once again illustrates that even well-designed languages can have security risks. It reminds us of the importance of code auditing and the need for more comprehensive security considerations in language design. For the Move language, adding more checks at runtime may be a direction for improvement.