Analysis of Solidity Compiler Vulnerabilities and Countermeasures

A compiler is one of the fundamental components of modern computer systems, and its main function is to convert source code written in high-level programming languages into executable instruction code for computers.

Although most developers and security personnel focus more on the security of application code, the security of the compiler itself cannot be ignored. As a computer program, the compiler may also have security vulnerabilities, which in some cases can lead to serious security risks. For example, when a browser compiles and executes JavaScript frontend code, vulnerabilities in the JavaScript parsing engine may allow attackers to execute remote code when users visit malicious web pages, ultimately leading to attackers gaining control over the victim's browser or even operating system.

The Solidity compiler is no exception; multiple versions of the Solidity compiler contain security vulnerabilities. The role of the Solidity compiler is to convert smart contract code into Ethereum Virtual Machine ( EVM ) instruction code, which will ultimately be executed in the EVM.

It is important to note that vulnerabilities in the Solidity compiler are different from vulnerabilities in the EVM itself. EVM vulnerabilities refer to security issues that arise when the virtual machine executes instructions, which can affect the entire Ethereum network. On the other hand, vulnerabilities in the Solidity compiler occur when converting Solidity code into EVM code; they do not directly impact the Ethereum network, but may cause the generated EVM code to differ from what the developer expected.

One of the dangers of Solidity compiler vulnerabilities is that they may lead to the generated EVM code being inconsistent with the expectations of smart contract developers. Since smart contracts on Ethereum often involve users' cryptocurrency assets, any bugs caused by the compiler could result in the loss of user assets, with serious consequences.

Developers and contract auditors often focus more on the logical implementation of contract code and security issues at the Solidity level, while neglecting compiler vulnerabilities. It is difficult to identify compiler vulnerabilities solely through auditing contract source code; analysis needs to be combined with specific compiler versions and specific code patterns.

Below are several real examples of Solidity compiler vulnerabilities:

1. SOL-2016-9 HighOrderByteCleanStorage

The vulnerability exists in early versions of the Solidity compiler ( >= 0.1.6 < 0.4.4). In certain cases, the compiler fails to properly clear the high-order bytes, resulting in the high-order 1 bit being written to storage after an integer overflow, overwriting the values of adjacent variables. This unexpected behavior can lead to serious consequences when it involves permission validation or asset accounting.

2. SOL-2022-4 InlineAssemblyMemorySideEffects

The vulnerability exists in the compilers from version 0.8.13 to 0.8.15. Due to issues with the compiler optimization strategy, in certain cases, it may mistakenly remove memory write instructions, resulting in function return values that do not match expectations. This optimization-related bug is difficult to detect through simple code review.

3. SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

The vulnerability affects compiler versions 0.5.8 to 0.8.16. When performing abi.encode operations on arrays of calldata type, the compiler incorrectly cleared certain data, resulting in the modification of adjacent data, causing inconsistencies in the encoded and decoded data. This issue may also occur during external calls and emit events, as these operations implicitly execute abi.encode.

Based on the analysis of vulnerabilities in the Solidity compiler, the following security recommendations are provided:

For Developers:

• Use a newer version of the Solidity compiler, known security issues are usually fewer.
• Improve unit test cases to increase code coverage, which helps to identify issues caused by the compiler.
• Avoid using inline assembly, complex ABI encoding and decoding operations; use new features and experimental functionalities with caution.

To security personnel:

• Consider the security risks that compilers may introduce during audits.
• Urge the upgrade of the compiler version in the SDL process, and consider introducing automatic version checks in CI/CD.
• Assess the actual impact of compiler vulnerabilities based on the specific circumstances of the project to avoid excessive concern.

Some practical resources:

• Official security warning released by Solidity
• Regularly updated bug list in the Solidity repository
• Bug list for various compiler versions, can be used for automatic checking.
• Etherscan contract code page compiler vulnerability alert

In conclusion, while vulnerabilities in Solidity compilers are not common, they can have serious consequences. Developers and security personnel should remain vigilant and take appropriate measures to mitigate risks.