A new integer overflow vulnerability discovered in the Move language reference safety mechanism

Recently, during an in-depth study of the Move language, we discovered a new integer overflow vulnerability. This vulnerability occurs in the reference security verification process and involves some core mechanisms of the Move language. By analyzing this vulnerability, we can gain a deeper understanding of the design and implementation of the Move language.

The Verification Process of Move Language

The Move language verifies code units before executing bytecode, and this process is divided into four steps. The vulnerability discovered this time occurs in the reference_safety step.

The reference_safety module defines the core functions used to verify reference safety. It mainly checks for issues such as the existence of dangling references, whether mutable reference access is safe, and whether global storage reference access is safe.

The entry function of the verification process will call analyze_function to analyze each function. analyze_function will verify each basic block in the function. A basic block refers to a sequence of code that has no branching instructions except for entry and exit.

Reference Safety in Move Language

Move language supports two types of references: immutable reference (&) and mutable reference (&mut). Immutable references are used for reading data, while mutable references are used for modifying data. This design helps improve the safety and readability of the code.

The reference security verification module scans the bytecode instructions of each basic block in the function to determine whether all reference operations are legal. The verification process mainly includes:

1. Execute basic block code
2. The status before and after merging execution
3. Update Block Status
4. Propagate postconditions to subsequent blocks

This process is similar to the Sea of Nodes concept in the V8 turbofan.

Vulnerability Analysis

The vulnerability occurs during the process of merging execution before and after the state. When the length of the function parameters plus the length of local variables exceeds 256, it can lead to integer overflow because the local variable index is represented using the u8 type.

Although the Move language has a process for verifying the number of local variables, this verification does not include the length of parameters. It seems that developers realized the need to check the total of parameters and local variables, but the actual code only checks the number of local variables.

This integer overflow could lead to a denial of service attack ( DoS ). An attacker can construct a loop code block that exploits the overflow to change the state of the block. When the basic block is executed again, if the index that the instruction needs to access does not exist in the new state, it will cause the program to crash.

Exploit

We constructed a proof of concept ( PoC ) to demonstrate this vulnerability:

1. Create a basic block containing unconditional branch instructions to execute it multiple times.
2. Set the total number of parameters and local variables to 264, causing the new local variable mapping length to overflow to 8.
3. When executing the basic block again, attempting to access a non-existent local variable index causes a panic.

Conclusion

This vulnerability once again proves that there is no such thing as completely secure code. Although the Move language performs static checks before execution, it can still be circumvented by integer overflow vulnerabilities.

For the future development of the Move language, we suggest:

1. Add more check code during runtime to prevent unexpected situations.
2. Do not rely solely on security checks during the verification phase; security hardening should also be conducted during the operational phase.

As a pioneer in Move language security research, we will continue to delve into the security issues of Move and contribute to its development.