A new integer overflow vulnerability found in the Move language's reference safety module

Recently, during an in-depth study of the Move language, we discovered a new integer overflow vulnerability. This vulnerability exists in the reference safety verification process, and its triggering process is quite interesting. This article will analyze this vulnerability in depth and explore some background knowledge of the Move language.

The Move language performs code unit validation before executing bytecode, which is divided into four steps. This vulnerability occurs in the reference_safety step. This step is responsible for verifying the safety of references, including checking for dangling references, whether mutable reference access is safe, and whether global storage reference access is safe, etc.

The entry function for citation security verification will call analyze_function to verify each basic block. A basic block refers to a sequence of code that has no branch instructions except for entry and exit. The Move language identifies basic blocks by traversing the bytecode, looking for all branch instructions and loop instruction sequences.

The Move language supports two types of references: immutable references (&) and mutable references (&mut). The reference safety module verifies the legality of all reference operations by scanning the bytecode instructions of basic blocks in functions. The verification process uses the AbstractState structure, which contains the borrow graph and locals, to ensure the safety of references within the function.

The vulnerability occurs in the join_ function. When the sum of the parameter length and the local variable length exceeds 256, it causes an integer overflow because the iter_locals() function returns an iterator of u8 type. Although Move has a process to check the number of locals, the check bounds module only verifies the locals and does not include the parameter length.

This integer overflow may lead to a Denial of Service (DoS) attack. When there is a loop code block and the overflow alters the block's state, the new locals map differs from the previous one. When the execute_block function is executed again and the index that the instruction needs to access does not exist in the new AbstractState locals map, it will result in a DoS.

We have provided a reproducible PoC in git. The code block in this PoC contains an unconditional branch instruction that jumps back to the first instruction every time the last instruction is executed, thus repeatedly calling the execute_block and join functions.

This vulnerability demonstrates that even a language focused on security like Move may have security risks. The importance of code auditing is self-evident, and programmers are bound to have oversights. As leaders in the security research of the Move language, we will continue to delve into the security issues of Move.

We recommend that Move language designers add more check codes at runtime to prevent unexpected situations. Currently, Move mainly conducts security checks during the verify phase, but this may not be enough. Once verification is bypassed, the lack of sufficient security reinforcement during the execution phase could lead to more serious issues.