Analysis of Solidity Compiler Vulnerabilities and Countermeasures

A compiler is one of the fundamental components of modern computer systems. It is a type of computer program whose main function is to convert high-level programming language source code, which is easy for humans to understand and write, into executable instruction code that can be processed by the underlying CPU or a bytecode virtual machine.

Most developers and security personnel usually focus on the security of application code, but may overlook the security of the compiler itself. In fact, compilers, as a type of computer program, can also have security vulnerabilities, which in certain cases can pose serious security risks. For example, during the process of compiling and parsing Javascript frontend code, a vulnerability in the Javascript parsing engine may allow attackers to exploit the vulnerability to achieve remote code execution when users visit malicious webpages, ultimately gaining control over the victim's browser or even the operating system.

The Solidity compiler is no exception; it has security vulnerabilities across multiple different versions.

Solidity Compiler Vulnerability

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

It is necessary to distinguish between vulnerabilities in the Solidity compiler and vulnerabilities in the EVM itself. EVM vulnerabilities refer to security issues that arise when the virtual machine executes instructions. Since attackers can upload arbitrary code to Ethereum, this code will ultimately run in every Ethereum P2P client program. If there are security vulnerabilities in the EVM, it will affect the entire Ethereum network, potentially causing a denial of service (DoS) or even allowing attackers to take over the entire chain completely. However, due to the relatively simple design of the EVM and the fact that core code is not frequently updated, the likelihood of such issues occurring is relatively low.

The Solidity compiler vulnerability refers to issues that occur when the compiler converts Solidity into EVM code. Unlike a browser scenario where JavaScript is compiled and run on the user's client computer, the Solidity compilation process occurs only on the smart contract developer's computer and does not run on Ethereum. Therefore, Solidity compiler vulnerabilities do not directly affect the Ethereum network itself.

A major risk of vulnerabilities in the Solidity compiler is that it may lead to discrepancies between the generated EVM code and the expectations of smart contract developers. Since smart contracts on Ethereum often involve users' cryptocurrency assets, any bugs in smart contracts caused by the compiler could result in loss of user assets, leading to serious consequences.

Developers and contract auditors may focus on issues related to the implementation logic of contract code, as well as security issues at the Solidity level such as reentrancy and integer overflow. However, it is difficult to detect vulnerabilities in the Solidity compiler solely through auditing the contract source code logic. It is necessary to analyze specific compiler versions in conjunction with specific code patterns to determine whether the smart contract is affected by compiler vulnerabilities.

Example of Solidity Compiler Vulnerability

The following examples illustrate several real vulnerabilities in Solidity compilers, showcasing their specific forms, causes, and harms.

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

The storage variable b has not been modified, so the function run() should return the default value 0. However, in the code generated by the vulnerable version of the compiler, run() will return 1.

Without understanding the vulnerabilities of the compiler, it is difficult for ordinary developers to discover the bugs present in the above code through simple code review. This example code is relatively simple and may not cause particularly severe harm. However, if the variable b is used for purposes such as permission verification or asset accounting, this inconsistency with expectations could lead to very serious consequences.

The reason for this anomaly is that the EVM uses a stack-based virtual machine, where each element in the stack is 32 bytes in size, which is the size of a uint256 variable. On the other hand, each slot in the underlying storage is also 32 bytes in size. The Solidity language supports various data types smaller than 32 bytes, such as uint32. When the compiler processes such variable types, it needs to perform appropriate cleanup operations on their high bits to ensure data integrity. In the aforementioned situation, when an integer overflow occurs during addition, the compiler did not correctly clean up the high bits of the result, resulting in a 1 bit being written into storage after the overflow, ultimately overwriting the variable b that follows variable a, causing the value of variable b to be changed to 1.

( SOL-2022-4 InlineAssemblyMemorySideEffects

The vulnerability exists in compilers with 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; } }

The Solidity compiler, during the process of converting Solidity language into EVM code, is not just a simple translation. It also performs in-depth control flow and data analysis, implementing various compilation optimization processes to reduce the size of the generated code and optimize gas consumption during execution. Such optimization operations are common in compilers of various high-level languages, but due to the complexity of the situations that need to be considered, it is also easy to introduce bugs or security vulnerabilities.

The vulnerability in the above code originates from such optimization operations. Consider a scenario where there is code in a certain function that modifies the data at memory offset 0, but there is no subsequent use of that data anywhere. In this case, the code that modifies memory 0 can be directly removed, saving gas and not affecting the subsequent program logic.

This optimization strategy itself is not problematic, but in the specific implementation of the Solidity compiler code, such optimizations are only applied within a single assembly block. In the example code above, the writing to and accessing of memory 0 occur in two different assembly blocks, but the compiler only analyzes and optimizes individual assembly blocks. Since there are no read operations after writing to memory 0 in the first assembly block, it determines that the write instruction is redundant and will remove that instruction, resulting in a bug. In the vulnerable version, the f( function will return 0, whereas the above code should actually return the correct value 0x42.

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

The vulnerability affects compilers >= 0.5.8 < 0.8.16. Consider the following code:

solidity contract C { function f(uint8) calldata a( public pure returns )string memory### { return string(abi.encode[4]a)(; } }

Under normal circumstances, the variable a returned by the above code should be "aaaa". However, in the version with the vulnerability, it will return an empty string "".

The cause of the vulnerability is that Solidity incorrectly performed cleanup on certain data while executing abi.encode operations on arrays of the calldata type, resulting in modifications to adjacent data and causing inconsistencies in the encoded and decoded data.

It is worth noting that when Solidity performs external calls and emits events, it implicitly applies abi.encode to the parameters, so the probability of the aforementioned vulnerability occurring is higher than one might intuitively think.

![Analysis of Solidity Compiler Vulnerabilities and Countermeasures])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(

Security Recommendations

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

To developers:

• Use a newer version of the Solidity compiler. Although new versions may also introduce new security issues, the known security issues are usually fewer than those in older versions.

• Improve unit test cases. Most compiler-level bugs can cause the execution results of the code to be inconsistent with expectations. These types of issues are difficult to detect through code reviews, but they can easily be exposed during the testing phase. Therefore, by increasing code coverage, such problems can be minimized.

• Try to avoid using inline assembly, complex operations such as ABI encoding and decoding for multi-dimensional arrays and complex structures. Avoid blindly pursuing flashy techniques and using new language features and experimental functionalities without clear requirements. According to the analysis of historical vulnerabilities, most vulnerabilities are related to inline assembly, ABI encoders, and similar operations. Compilers are indeed more prone to bugs when handling complex language features. On the other hand, developers are also likely to make usage mistakes when using new features, leading to security issues.

To security personnel:

• When conducting a security audit of Solidity code, do not overlook the security risks that may be introduced by the Solidity compiler. The corresponding check item in Smart Contract Weakness Classification(SWC) is SWC-102: Outdated Compiler Version.

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

• However, there is no need to panic excessively about compiler vulnerabilities. Most compiler vulnerabilities are triggered only under specific code patterns, and not all contracts compiled with a vulnerable version of the compiler necessarily have security risks. The actual security impact needs to be assessed specifically based on the project's situation.

Some practical resources:

• Security alerts regularly issued by the Solidity team:

• Bug list updated regularly from the official Solidity repository:

• Bug list for each version of the compiler:

Code page of Etherscan, the triangle exclamation mark in the upper right corner indicates the security vulnerabilities present in the current version of the compiler.

Summary

This article begins with the basic concepts of compilers, introduces vulnerabilities in the Solidity compiler, and analyzes the potential security risks they may pose in actual Ethereum development environments. Finally, it offers several practical security recommendations for developers and security personnel.

![Analysis of Solidity Compiler Vulnerabilities and Countermeasures])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(