Analysis of Solidity Compiler Vulnerabilities and Countermeasures

A compiler is one of the fundamental components of modern computer systems. It is a program that translates high-level programming languages into machine-executable instructions. While developers and security experts often focus on the security of application code, the security of the compiler itself is equally important.

Compilers, as computer programs, may also have security vulnerabilities, which can pose serious security risks in certain situations. For example, when browsers parse and execute JavaScript code, vulnerabilities in the JavaScript engine may allow attackers to compromise a user's browser or even their operating system when the user accesses a malicious webpage.

The Solidity compiler is no exception. According to security warnings from the Solidity development team, there are security vulnerabilities in multiple versions of the Solidity compiler.

Solidity Compiler Vulnerabilities

The role of the Solidity compiler is to convert smart contract code into Ethereum Virtual Machine ( EVM ) instruction code. These EVM instructions are packaged and uploaded to Ethereum through transactions, and ultimately executed by the EVM.

It is necessary to differentiate between vulnerabilities in the Solidity compiler and vulnerabilities in the EVM itself. EVM vulnerabilities refer to security flaws that occur when the virtual machine executes instructions, which may affect the entire Ethereum network. On the other hand, vulnerabilities in the Solidity compiler refer to issues that arise when converting Solidity into EVM code.

The Solidity compiler vulnerability does not directly affect the Ethereum network, but it may lead to the generated EVM code being inconsistent with the developer's expectations. Since smart contracts often involve cryptocurrency assets, any bugs caused by the compiler could result in user asset losses, with serious consequences.

It is difficult to identify compiler vulnerabilities solely by auditing the contract source code. It is necessary to analyze it in conjunction with specific compiler versions and code patterns to determine whether the contract is affected by compiler vulnerabilities.

Example of Solidity Compiler Vulnerability

Here are several real examples of Solidity compiler vulnerabilities, demonstrating their specific forms, causes, and dangers.

SOL-2016-9 HighOrderByteCleanStorage

The vulnerability exists in earlier versions of the Solidity compiler ( >=0.1.6 <0.4.4).

Consider the following code:

solidity contract C { uint32 a = 0x12345678; uint32 b = 0; function run() returns (uint256) { a = a + 1; return b; } }

The storage variable b is unchanged, and the run() function should return the default value 0. However, in vulnerable versions of the compiler, run() will return 1.

This unexpected situation, if the b variable is used for purposes such as permission verification or asset accounting, could lead to serious consequences.

The reason for this phenomenon is that the EVM uses 32-byte-sized stack elements and storage slots, while Solidity supports smaller data types like uint32. The compiler needs to clear the high bits when handling these types, but it did not handle integer overflow correctly, resulting in the high bit 1 being written to storage, which overwrote the b variable.

SOL-2022-4 InlineAssemblyMemorySideEffects

The vulnerability exists in compiler versions >=0.8.13 <0.8.15.

Consider the following code:

solidity contract C { function f() public pure returns (uint) { assembly { mstore(0, 0x42) } uint x; assembly { x := mload(0) } return x; } }

This vulnerability stems from compiler optimization. The compiler attempts to remove seemingly redundant memory write operations but incorrectly analyzes across assembly blocks. In the vulnerable version, function f() will return 0 instead of the correct 0x42.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

The vulnerability affects compilers from version >= 0.5.8 to < 0.8.16.

Consider the following code:

solidity contract C { function f(string[1] calldata a) external pure returns (string memory) { return abi.decode(abi.encode(a), (string[1]))[0]; } }

Under normal circumstances, the code should return the value of the variable a as "aaaa". However, in the vulnerable version, it will return an empty string "".

This is due to Solidity incorrectly clearing certain data when performing abi.encode operations on calldata type arrays, leading to modifications of adjacent data, resulting in inconsistent data after encoding and decoding.

It is worth noting that Solidity implicitly executes abi.encode when making external calls and emitting events, so the impact of such vulnerabilities may be broader than expected.

Security Recommendations

Based on the analysis of the threat model of Solidity compiler vulnerabilities and the historical vulnerabilities review, the following recommendations are provided for developers and security personnel:

For Developers:

1. Use a newer version of the Solidity compiler. Newer versions usually fix known security issues.

2. Improve unit testing. Most compiler-level bugs can cause the code execution results to differ from expectations. By increasing code coverage, such issues can be discovered during the testing phase.

3. Avoid using inline assembly, complex ABI encoding and decoding, and other operations. Most historical vulnerabilities are related to these complex features.

for security personnel:

1. Do not overlook the security risks that compilers may introduce during the audit. The relevant Smart Contract Weakness Classification ( SWC ) checklist item is SWC-102.

2. In the internal SDL process, urge the development team to upgrade the Solidity compiler version and consider introducing automated checks in CI/CD.

3. There is no need to worry excessively about compiler vulnerabilities. Most vulnerabilities are only triggered under specific code patterns and need to be assessed for actual impact based on the specific situation.

Practical Resources:

• Security alert released by the Solidity team:
• Official Solidity bug list:
• Bug list for each version of the compiler:
• The warning sign in the upper right corner of the Etherscan contract code page can indicate security vulnerabilities in the current version of the compiler.

Summary

This article introduces the concept of Solidity compiler vulnerabilities, analyzes the security risks they may pose in actual Ethereum development, and provides practical security advice for developers and security personnel. By understanding the characteristics and impacts of compiler vulnerabilities, the security of smart contracts can be better ensured.