Analysis of Solidity Compiler Vulnerabilities and Countermeasures

The compiler is one of the core components of modern computer systems. It translates high-level programming languages that are understandable by humans into low-level instructions that can be executed by computers. While developers and security experts often focus on the security of application code, the security issues of the compiler itself should not be overlooked. Compiler vulnerabilities can pose serious security risks in certain situations.

For example, in a browser, vulnerabilities in the JavaScript engine during the parsing and execution of JavaScript code may allow remote code execution attacks when users visit malicious web pages, ultimately enabling attackers to control the victim's browser or even operating system. Additionally, bugs in C++ compilers may also lead to serious consequences such as remote code execution.

The Solidity compiler is no exception; there are security vulnerabilities across multiple versions. The function of the Solidity compiler is to convert smart contract code into Ethereum Virtual Machine ( EVM ) bytecode, which is ultimately executed in the EVM. It's 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. In contrast, vulnerabilities in the Solidity compiler occur during the conversion of Solidity to EVM code.

One of the dangers of Solidity compiler vulnerabilities is that the generated EVM code may not match the developer's expectations. Since smart contracts often involve users' cryptocurrency assets, any bugs caused by the compiler could result in significant losses of user assets, with severe consequences. Developers and auditors often focus on the implementation of contract logic and common vulnerabilities, while compiler vulnerabilities require analysis in conjunction with specific versions and code patterns.

The following will showcase the specific forms, causes, and dangers of Solidity compiler vulnerabilities through several real cases.

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 f() public { a = a + 1; } function run() public view returns (uint32) { return b; } }

Variable b has not been modified, and the function run() should return the default value 0. However, in the code generated by the compiler in the vulnerable version, run() returns 1.

This inconsistency is difficult to detect through simple code reviews. Although the example code has limited impact, if the variable b is used for permission validation or asset accounting, the consequences could be very serious.

The reason for this issue is that the EVM uses 32-byte size stack elements, and each slot of the underlying storage is also 32 bytes. Solidity supports data types smaller than 32 bytes, such as uint32, and the compiler needs to clear the high bits when handling these types to ensure data integrity. In this case, after the addition overflow, the compiler did not correctly clear the high bits of the result, causing the overflowed 1 bit to be written into storage, overwriting the variable b.

SOL-2022-4 InlineAssemblyMemorySideEffects

This vulnerability exists in the compiler versions from 0.8.13 to 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; } }

The Solidity compiler performs in-depth control flow and data analysis during the optimization process to reduce the size of the generated code and optimize gas consumption. This type of optimization is common, but due to the complexity of the situation, bugs or security vulnerabilities can easily occur.

The issue with the above code stems from this type of optimization. The compiler assumes that if a function modifies data at memory offset 0, but that data is not used subsequently, it can remove the modification instruction to save gas. However, this optimization only applies within a single assembly block.

In this example, the write and access to memory 0 occur in two different assembly blocks. The compiler only analyzed the individual assembly blocks and deemed the write in the first block as redundant, thus removing it, which resulted in a bug. In the vulnerable version, the f() function will return 0, while the correct return value should be 0x42.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

This vulnerability affects compilers from version 0.5.8 to 0.8.16. Consider the following code:

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

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

The problem lies in Solidity's abi.encode operation on calldata type arrays, which incorrectly cleans up certain data, resulting in modifications to adjacent data and causing inconsistencies in the encoded and decoded data.

It is worth noting that Solidity implicitly performs abi.encode on parameters when making external calls and emitting events, so the impact of this vulnerability may be greater than expected.

Security Suggestions

Based on the analysis of vulnerabilities in the Solidity compiler, the following suggestions are made for developers and security personnel:

To Developers:

• Use a newer version of the Solidity compiler. While new versions may introduce new issues, they typically have fewer known security problems.
• Improve unit testing. Most bugs at the compiler level can cause the execution results to differ from expectations; these issues are difficult to detect through code reviews but can easily be exposed in tests. Increasing code coverage can minimize such problems.
• Avoid using inline assembly, complex ABI encoding and decoding operations, and do not blindly use new features and experimental functionalities. Most historical vulnerabilities are related to these complex operations.

To security personnel:

• Do not ignore the security risks that compilers may introduce during the audit. The corresponding check item in Smart Contract Weakness Classification)SWC[0] is SWC-102: Outdated Compiler Version.
• In the SDL development process, urge the development team to upgrade the compiler version and consider introducing automatic checks for the compiler version in CI/CD.
• There is no need to excessively worry about compiler vulnerabilities. Most vulnerabilities are only triggered under specific code patterns, and contracts compiled with vulnerable versions do not necessarily pose a risk; it needs to be assessed based on the specific situation.

Some practical resources:

• Security alerts regularly released by the Solidity team
• The official Solidity repository regularly updates its bug list.
• Bug list for various versions of the compiler, can be used for automatic checks in CI/CD.
• The warning icon in the upper right corner of the Etherscan contract code page can indicate any security vulnerabilities present in the current version of the compiler.

Summary

This article introduces the concept of Solidity compiler vulnerabilities, analyzes the potential security risks they may pose in Ethereum development, and provides practical security advice for developers and security personnel. Although compiler vulnerabilities are rare, their impact is significant and worthy of attention from development and security teams.