Beosin security team officially announces the security audit service for Move smart contracts, aiming to discover and assist project owners to fix security risks in advance, and safeguard the assets of users and projects.

In the previous article, we discussed the features of the Move language in depth and introduced the design of Move from a security perspective. In this article, we will further deepen the understanding of Move by comparing it with solidity, and then introduce the possible security vulnerabilities and corresponding audit items of Move projects summarized by our research team.

1. Move vs. Solidity

1.1 Account Module

Solidity:

In most Ethereum ERC-20 contracts, the balance of each address is stored in a type of state variable mapping(address => uint256), which is stored in the global storage of the particular smart contract. The structure is shown below.

Move：

In Move, modules analogous to Solidity smart contracts have no storage space of their own. Instead, Move’s “global storage” is indexed by addresses, each of which stores Move modules and Move resources, and the resource storage is a mapping of types to values. The structure is shown in the following diagram.

1.2 Code Storage

Solidity：

In an EVM-based chain, all smart contracts have a unique address, called a “Contract Owner Address”. The contract account exists at the same level as the deployer account (EOA), and the code hash is stored in the contract account address, which is not tied to the deployer address after the contract is deployed.

MOVE：

In the MoveVM-based chain, the code is stored in the code module of the Account resource.

1.3 Security Isolation

Solidity：

The running environment of a smart contract is a sandbox environment constructed by the nodes of the chain, and multiple contract programs are different virtual machine sandboxes running within the same process. The calls between smart contracts are between different smart contract VMs within the same process, and security is completely dependent on the isolation between smart contract VMs.

Move：

Move’s approach is to make blockchains with the Move language deterministic through MoveVM, placing contract calls in the same virtual machine sandbox and isolating the state of smart contracts through security within the programming language, rather than relying on the virtual machine for isolation.

1.4 Contract Upgrade

Solidity：

The way to upgrade a contract in EVM is to analyze the contract data and logic: the Proxy contract is responsible for forwarding transactions to the Logic contract and saving the contract data; the Logic contract is responsible for implementing the functional logic. When upgrading, you only need to redeploy the new version of the logical contract and point the logical contract instance in the proxy contract to the new version of the logical contract instance. At this point, the upgrade of the logical contract does not affect the original data of the contract.

As shown below, the code store field specifies the contract code that does the delegate call when the agent can contract is invoked. A contract upgrade is essentially deploying a new logical contract and changing the code field to redirect the delegate call.

Move：

The implementation of the Move language for contract upgrades is to execute the upgrade logic in the system module code.move, which checks the upgrade policy and compatibility before the code is deployed. After the compatibility check, the code written in resource is replaced by a native function call and the new logic is executed.

Source: https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-framework/sources/code.move#L132

2. Possible Vulnerabilities in Move Programs

1) Developers should maintain a degree of security awareness when developing with Aptos, Sui, or other unique Frameworks in Move-based blockchains to ensure supply chain security.

2) Function permission issues. Permissions for some function calls should be carefully delineated, because some key functions will involve governance and seriously affect the security of funds, and for such function calls the caller needs to be authenticated.

3) The design and code implementation of business logic should pay attention to the logic issues.

4) With regard to the Move project, the following points need to be noted when upgrading modules.

- The owner of the code has full control over the upgrade permissions according to the contract upgrade policy.

- The owner of the code is immutable after the initial deployment.

- The deployer’s address will always have upgrade privileges after deployment.

3. Move Audit Service & Audit Categories

Beosin security team has officially launched the security audit service for Move smart contracts, which includes the following security audit items.

- Overflow vulnerability

- Replay attack

- Insecure random numbers

- Transaction-ordering dependency

- Denial of Service

- Access control

- Improper permissions

- Variable override

- Business design

- Business implementation

- Manipulable token prices

- Arbitrage attacks

- Gas optimization

- Third party module security

- Ability Security

- Resource Security

- Upgrade Security

- Centralization risk

References

https://developers.diem.com/docs/technical-papers/move-paper/

https://mirror.xyz/asmp.eth/xUzqdBXewRPhLKLAYekiwU5S9uFiTnJ3f56KbkcOz-M

https://mirror.xyz/jolestar.eth/sQ0nMCO3eNig6gCzqQO7xew1mn8oUi1-rKtfZKmGlNI

https://medium.com/@kklas/smart-contract-development-move-vs-rust-4d8f84754a8f

Contact

If you have need any blockchain security services, please contact us:

Website Email Official Twitter Alert Telegram LinkedIn