In November 2023, Professor Zhou Yajin, CEO of BlockSec, was invited to participate in the first Web3 Scholars Summit hosted by DRK Lab. During the conference, Professor Zhou shared BlockSec's work and achievements in detecting vulnerabilities in the EVM (Ethereum Virtual Machine). He also introduced BlockSec's automated differential fuzzing tool specifically designed to ensure the security of EVM-compatible chains. This article summarizes the content of the speech.
Introduction
According to Defillama's data statistics, there are currently 238 L1 and L2 public chains, with 144 of them being EVM-compatible. However, the question arises: Do these EVM-compatible chains have any security issues during their implementation? After conducting our research, the answer is affirmative. In response to this concern, BlockSec has launched an automated differential fuzzing security tool. Join us as we embark on a journey to explore the truth behind these EVM-compatible chains.
Vulnerabilities in Virtual Machines
Taking the Ethereum Virtual Machine (EVM) as an example, it adopts a stack-based architecture including Virtual ROM, Program Counter, Stack, Memory, and World State (persistent).
A virtual machine acts as the engine that interprets and executes the compiled binary code of smart contracts. The core component of many blockchain platforms is the virtual machine, with the Ethereum Virtual Machine (EVM) being particularly notable. Therefore, the virtual machine plays a key role in executing smart contracts, processing transactions, and ensuring the integrity of the blockchain.
We know that the EVM itself is also a software program written by programmers. However, how can we ensure that the EVM is free of issues? After all, bugs are possible in any code written by humans.
And once a bug appears in the EVM, it will have catastrophic consequences for the ecosystem on the blockchain. In fact, the EVM has encountered many serious vulnerabilities in the past.
For instance, in 2020, there was a vulnerability incident caused by a precompiled contract (i.e., CVE-2020-26241) [1]. The dataCopy precompiled contract in Geth (located at 0x00...04) protocol performed a shallow copy during invocation, where copying a large amount of data only copied the pointers instead of the complete data. This allowed malicious smart contracts to modify data that should not have been modified, resulting in data inconsistency when different versions of the virtual machine executed the same smart contract. Another example occurred in 2021 when certain EVM-compatible chains did not upgrade alongside Ethereum. In older versions of Geth, there was a vulnerability (CVE-2021-39137) [2] where the memory regions for input and output data in precompiled contract calls overlapped. Attackers exploited this vulnerability, resulting in a chain fork.
BlockSec's Countermeasures
How do timely discover vulnerabilities in the EVM? What are the challenges?
-
Firstly, due to the intricate design of the virtual machine, it is challenging to find tools that can fully comprehend its operational logic. Each field of expertise requires specialization, many developers may not be able to invest a sufficient amount of effort to understand its operational logic and take effective precautions.
-
Additionally, many L1/L2 new public chains customize the EVM virtual machine, which can potentially introduce new security issues.
Clearly, relying solely on manual audits to identify these issues on the EVM virtual machine is difficult.
Adapt and respond accordingly! In light of these challenges, BlockSec has developed an automated system to tackle these issues head-on!
Differential Fuzzing
At BlockSec, our team of experts has employed a clever approach known as differential fuzzing. By executing the same test cases on different versions of the virtual machine and comparing the output results, we can uncover potential vulnerabilities and inconsistencies. This method allows us to effectively identify subtle differences that conventional testing methods might overlook, thereby enhancing the overall security of the system.
Basic Working Principle:
To conduct differential fuzzing, we need to prepare identical inputs as test cases. These test cases are then fed into the differential fuzzing engine. By comparing the outputs of executing the same test cases on different versions of the virtual machine, we can identify potential issues.
Specific Implementation Steps:
The test case for differential fuzzing needs to consist of two parts: transaction metadata and pre-state. But how do we generate these transactions? We have two approaches to tackle this challenge.
- Reuse historical transactions: We can retrieve the historical transactions that have occurred on the blockchain and run them through different versions of the virtual machine in the differential fuzzing engine. However, relying solely on this method has its limitations. Historical transactions tend to be too "normal", whereas security testing requires uncovering corner cases—the exceptional scenarios. That's why we came up with a second approach.
- Coverage-guided fuzzing: We generate uncommon bytecode and historically unseen transactions from scratch, then mutate the transactions and smart contract code and input them into the virtual machine. We ensure the validity and comprehensiveness of test cases from various dimensions.
Once these transactions are generated, they are fed into the differential fuzzing engine, and the results are then compared.
The comparison of results is not merely a simple numerical comparison but also comprehensively considers data consistency in both persistent and non-persistent storage in the virtual machine. This article will no longer elaborate further.
Case Study
I'd like to share a virtual machine vulnerability case we discovered in the Aurora VM through differential fuzzing. Specifically, it relates to an issue with the ModExp precompiled smart contract.
When computing the modular exponentiation of a number x raised to the power y, we are aware that this operation requires computational resources. In a correct implementation, the gas calculation takes into account the number of iterations since modular exponentiation involves multiple iterations. However, there is a specific scenario where the gas calculation can encounter an issue: when the exponent y equals 0, indicating a zeroth-order power operation. In this case, the number of iterations becomes zero, resulting in an extremely small gas value. But in fact, the calculation still requires resources.
Conclusion
Currently, the differential fuzzing tool launched by BlockSec supports execution in the environments of various blockchain virtual machines, including rbpf, ubpf, Aurora-engine, neon-evm, Moonbeam, revm, EvmOS, fevm, and Polygon-zkevm, with continuous expansion.
With this tool, we have discovered 14 new vulnerabilities, applied for 2 CVEs: CVE-2021–46102 and CVE-2022–23066, and received over $1.3 million in bug bounties.
At present, the comprehensive EVM chain security solution provided by BlockSec (audit services + differential fuzzing tools) has been recognized and adopted by EOS and FileCoin and will contribute to the security and healthy development of their ecosystems.
Reference
[1] Shallow copy in the 0x4 precompile could lead to EVM memory corruption
[2] RETURNDATA corruption via datacopy
About BlockSec
BlockSec is a pioneering blockchain security company established in 2021 by a group of globally distinguished security experts. The company is committed to enhancing security and usability for the emerging Web3 world to facilitate its mass adoption. To this end, BlockSec provides smart contract and EVM chain security auditing services, the Phalcon platform for security development and blocking threats proactively, the MetaSleuth platform for fund tracking and investigation, and MetaDock extension for web3 builders surfing efficiently in the crypto world.
To date, the company has served over 300 esteemed clients such as MetaMask, Uniswap Foundation, Compound, Forta, and PancakeSwap, and received tens of millions of US dollars in two rounds of financing from preeminent investors, including Matrix Partners, Vitalbridge Capital, and Fenbushi Capital.
✉️Business consulting：contact@blocksec.com
Twitter account of BlockSec: https://twitter.com/BlockSecTeam
Twitter account of Phalcon: https://twitter.com/Phalcon_xyz
