Analysis of Solidity Compiler Vulnerabilities and Response Strategies

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 source code written in high-level programming languages, which are easy for humans to understand and write, into executable instruction code that can be run by a computer's underlying CPU or bytecode virtual machine.

Most developers and security experts usually focus on the security of application code, but may overlook the security issues of the compiler itself. In fact, compilers, as computer programs, also have security vulnerabilities, and these vulnerabilities can pose serious security risks under certain circumstances. For example, during the process of compiling and parsing JavaScript frontend code, a vulnerability in the JavaScript parsing engine may allow an attacker to exploit the vulnerability to execute remote code when a user visits a malicious webpage, ultimately taking control of the victim's browser or even operating system.

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

Solidity Compiler Vulnerabilities

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 inherent 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 leading to a complete denial of service (DoS) or even being completely controlled by attackers. However, due to the relatively simple design of the EVM and the fact that the core code is not frequently updated, the likelihood of such issues arising is low.

A Solidity compiler vulnerability refers to issues that arise when the compiler converts Solidity code into EVM code. Unlike scenarios where browsers compile and run JavaScript on the user's client machine, the Solidity compilation process occurs solely on the smart contract developer's machine and does not run on Ethereum. Therefore, Solidity compiler vulnerabilities do not affect the Ethereum network itself.

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

Developers and contract auditors may focus on issues related to the implementation of contract code logic, as well as security problems 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 logic of the contract source code. It requires a combined analysis of specific compiler versions and specific code patterns to determine whether the smart contract is affected by compiler vulnerabilities.

Example of Solidity Compiler Vulnerabilities

The following showcases several real cases of Solidity compiler vulnerabilities, demonstrating their specific forms, causes, and dangers.

SOL-2016-9 HighOrderByteCleanStorage

The vulnerability exists in early 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 (uint32) { return b; } }

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

If developers are not aware of this compiler vulnerability, it is difficult for ordinary developers to detect the bugs present in the above code through simple code reviews. This is just a simple example that will not lead to particularly serious consequences. However, if the variable b is used for purposes such as permission validation or asset accounting, this inconsistency with expectations could lead to very serious issues.

The reason for this strange phenomenon lies in the EVM using a stack-based virtual machine, where each element in the stack is 32 bytes in size, which is the same as 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, and when the compiler processes these types of variables, it needs to perform appropriate cleanup on the high bits to ensure data integrity. In the aforementioned situation, when addition results in integer overflow, the compiler did not correctly clean up the high bits of the result, causing a 1 bit from the overflow to be written into storage, ultimately overwriting the variable 'a' with the following variable 'b', modifying the value of 'b' to 1.

( SOL-2022-4 InlineAssemblyMemorySideEffects

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 vulnerability exists in the compiler versions >=0.8.13 <0.8.15. The Solidity compiler does not simply translate the Solidity language into EVM code. 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 for 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 arises from this type of optimization. If there is code in a certain function that modifies the data at memory offset 0, but there is no subsequent usage of that data, then the code modifying memory 0 can actually be removed directly, 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 to a single assembly block. In the above PoC code, the writing to and accessing of memory 0 exist in two different assembly blocks, while the compiler only analyzes and optimizes each individual assembly block. 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 removes it, resulting in a bug. In the vulnerable version, the function f() will return a value of 0, while the correct value that the above code should return is 0x42.

( SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Consider the following code:

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

The vulnerability affects compiler versions >= 0.5.8 and < 0.8.16. Normally, the variable a returned by the above code should be "aaaa". However, in the vulnerable version, it will return an empty string "".

The cause of the vulnerability is that Solidity incorrectly performed a clean-up on certain data when executing the abi.encode operation on arrays of the calldata type, leading to modifications of adjacent data and causing inconsistencies in the data after encoding and decoding.

It is worth noting that when Solidity performs external calls and emits events, it implicitly applies abi.encode to the parameters, making the occurrence of the aforementioned vulnerability more likely than one might intuitively feel.

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

Security Recommendations

The Cobo blockchain security team analyzed the threat model of vulnerabilities in the Solidity compiler and reviewed historical vulnerabilities, and has provided the following recommendations for developers and security personnel.

) to developers:

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

• Improve unit test cases. Most compiler-level bugs can lead to execution results that are inconsistent with expectations. Such issues are difficult to detect through code reviews but 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 using new language features and experimental functions for show-off without clear requirements. According to the Cobo security team's analysis of historical vulnerabilities in Solidity, most vulnerabilities are related to operations such as inline assembly and ABI encoders. The compiler is indeed more likely to have bugs when dealing with complex language features. On the other hand, developers are also prone to misuse when using new features, leading to security issues.

) for 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 the 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 only triggered under specific code patterns, and not all contracts compiled with vulnerable versions of compilers necessarily pose security risks. The actual security impact needs to be evaluated based on the specifics of the project.

Practical Resources:

• Security Alerts posts released periodically by the Solidity Team:

• The official Solidity repo regularly updates the bug list:

• Bug list for each version of the compiler:

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

Summary

This article starts with the basic concepts of compilers, introduces vulnerabilities in the Solidity compiler, and analyzes the potential security risks it may cause in actual Ethereum development environments. Finally, it provides 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(