How to Compare VMs

Author: Alexey Naberezhniy
Security researcher at MixBytes

How to check for vulnerabilities of these types?

What potential vulnerabilities exist in blockchains that have an Ethereum-like VM?

Complete Blockchain Shutdown Caused by Sending a Malicious Transaction

Blockchain is an open system that allows users to send any transactions that will be processed by a virtual machine. One of the potential vulnerabilities that can exist in blockchains is the lack of verification that the payload sent by the user will not completely stop the network since block producers are not be able to process this operation.

An example of the error in the Aptos VM

The following commands lead to a potential issue in the Aptos virtual machine:

Bytecode::VecPack(si, num)
Bytecode::VecUnpack(si, num)

The presence of these opcodes which interact with the stack results in a user's being able to add num (u64) elements to the stack (it's impossible in the Ethereum VM, since PUSH opcodes are limited).
In this place in code, it becomes possible to cause an overflow, since num_pushes are not validated in any way:
https://github.com/aptos-labs/move/blob/97a771cb6a2414ef3a68d71aef8f0bc6aac61ef2/language/move-bytecode-verifier/src/stack_usage_verifier.rs#L60
Calling an overflow in this place does not lead to the theft of funds, but causes a critical error in the node, and therefore in the entire blockchain. Since Aptos is a new network, this may cause the entire network to go down at the moment. To do this, it is enough for a hacker to send one malicious transaction. Ethereum is not susceptible to this type of vulnerability, as there are a number of alternative chain node implementations.

Source: https://medium.com/numen-cyber-labs/analysis-of-the-first-critical-0-day-vulnerability-of-aptos-move-vm-8c1fd6c2b98e

Incorrect implementation of precompiles

In order to optimize the execution of smart contracts, node chain developers add additional functionality that can be utilized directly from the virtual machine to speed up some complex functions (such as sha3, ecrecover, etc.). The easiest example to understand is JNI for communicating java bytecode with native code directly.
Examples of precompiles implementations:

https://github.com/ava-labs/coreth/tree/master/precompile
https://github.com/PureStake/moonbeam/tree/master/precompiles
Implementations of some precompiles may contain significant bugs, which can often lead to critical errors (such as DoS, Access Control, and others).

An example of an error in the Precompile (Avalanche)

An error in the precompile that caused some smart contracts to work incorrectly is presented below:
https://github.com/ava-labs/coreth/blob/8543a81bfd8e7812c181ff4fade6405396b0a1d6/core/vm/evm.go#L747

// https://snowtrace.io/address/0x0100000000000000000000000000000000000000

func (evm *EVM) NativeAssetCall(caller common.Address, input []byte, suppliedGas uint64, gasCost uint64, readOnly bool) (ret []byte, remainingGas uint64, err error) {
	if suppliedGas < gasCost {
		return nil, 0, vmerrs.ErrOutOfGas
	}
	remainingGas = suppliedGas - gasCost

    ...
    
    // Send [assetAmount] of [assetID] to [to] address
	evm.Context.TransferMultiCoin(evm.StateDB, caller, to, assetID, assetAmount)
	ret, remainingGas, err = evm.Call(AccountRef(caller), to, callData, remainingGas, new(big.Int))
    
    ...   
}

The smart contract code that was vulnerable due to an error in precompile:
https://github.com/Abracadabra-money/magic-internet-money/blob/23266d17969a95e69199670cba9d0060bff33340/contracts/CauldronV3_1.sol#L410

...
require(callee != address(bentoBox) && callee != address(this), "Cauldron: can't call");

(bool success, bytes memory returnData) = callee.call{value: value}(callData);
...

Before callee.call is called, there is a check for callee != address(bentoBox), which restricts the call to bentoBox. But if we call contract 0x0100000000000000000000000000000000000000 passing the call to bentoBox, then the require check can be bypassed.
After this vulnerability disclosure, this precompile was excluded from the node.

Source: https://medium.com/avalancheavax/apricot-phase-6-native-asset-call-deprecation-a7b7a77b850a

Network Attacks

Each blockchain node interacts with the outside world in one way or another. There are many interfaces, such as: RPC, admin interface, etc. An attacker is also able to attack the network via these interfaces.

Examples:

How to check for vulnerabilities of these types?

There are several options for finding vulnerabilities in Ethereum-like VMs:

Manual review. For example, manual analysis of instructions (e.g., for Avalanche you should examine the code at this link https://github.com/ava-labs/coreth/blob/master/core/vm/instructions.go).
Semi-automated study using tools. For example, Ethereum provides the EVM lab tool for this (https://github.com/ethereum/evmlab)
Automated study. For instance, a tool that compares all popular VM machines with each other using fuzz-generated transactions. (https://github.com/MariusVanDerWijden/FuzzyVM). Since all Ethereum-like VM environments should work in a similar way, we can pass the same environment and find all the differences through tracing (each such difference will be a potential vulnerability).
There is a very good tool for analyzing precompiles that allows you to find vulnerabilities (https://github.com/holiman/goevmlab/tree/master/cmd/precompile_fuzzer)

Who is MixBytes?

MixBytes is a team of expert blockchain auditors and security researchers specializing in providing comprehensive smart contract audits and technical advisory services for EVM-compatible and Substrate-based projects. Join us on X to stay up-to-date with the latest industry trends and insights.

Disclaimer

The information contained in this Website is for educational and informational purposes only and shall not be understood or construed as financial or investment advice.