Solidity编译器漏洞解析及应对策略

编译器是现代计算机系统的基本组成部分之一。它是一种计算机程序,主要功能是将人类易于理解和编写的高级程序语言源代码转换成计算机底层CPU或字节码虚拟机可执行的指令代码。

大多数开发者和安全人员通常会比较关注程序应用代码的安全,但可能会忽视编译器自身的安全性。事实上,编译器作为一种计算机程序,也存在安全漏洞,而这些漏洞在某些情况下可能带来严重的安全风险。例如,浏览器在编译并解析执行Javascript前端代码的过程中,可能由于Javascript解析引擎的漏洞,导致用户在访问恶意网页时被攻击者利用漏洞实现远程代码执行,最终完成对受害者浏览器甚至操作系统的控制。

Solidity编译器也不例外,在多个不同版本中都存在安全漏洞。

Solidity编译器漏洞

Solidity编译器的作用是将开发人员编写的智能合约代码转换成以太坊虚拟机(EVM)指令代码,这些EVM指令代码通过交易打包上传到以太坊上,最终由EVM解析执行。

需要将Solidity编译器漏洞与EVM自身的漏洞区分开来。EVM的漏洞是指虚拟机在执行指令时产生的安全问题。由于攻击者可以上传任意代码到以太坊上,这些代码最终将在每个以太坊P2P客户端程序中运行,如果EVM存在安全漏洞,将影响整个以太坊网络,可能造成整个网络的拒绝服务(DoS)甚至导致整个链完全被攻击者接管。不过,由于EVM本身设计相对简单,且核心代码不会频繁更新,因此出现上述问题的可能性相对较低。

Solidity编译器漏洞是指编译器将Solidity转换成EVM代码时存在的问题。与浏览器这种会在用户客户端计算机上编译运行Javascript的场景不同,Solidity编译过程只在智能合约开发者的计算机上进行,不会在以太坊上运行。因此Solidity编译器漏洞不会直接影响以太坊网络本身。

Solidity编译器漏洞的一个主要危害在于,可能导致生成的EVM代码与智能合约开发者的预期存在不一致。由于以太坊上的智能合约通常涉及用户的加密货币资产,因此编译器导致的任何智能合约bug都可能造成用户资产损失,产生严重后果。

开发者和合约审计人员可能会重点关注合约代码逻辑实现问题,以及重入、整数溢出等Solidity层面的安全问题。而对于Solidity编译器的漏洞,仅通过对合约源码逻辑的审计是很难发现的。需要结合特定编译器版本与特定的代码模式共同分析,才能确定智能合约是否受编译器漏洞的影响。

Solidity编译器漏洞示例

下面以几个真实的Solidity编译器漏洞为例,展示其具体形式、成因及危害。

SOL-2016-9 HighOrderByteCleanStorage

该漏洞存在于较早期的Solidity编译器版本中(>=0.1.6 <0.4.4)。

考虑如下代码:

solidity contract C { uint32 a = 0x1234; uint32 b = 0; function f() public { a += 1; } function run() public view returns (uint) { return b; } }

其中storage变量b没有经过任何修改,因此run()函数应该返回默认值0。但实际上,在存在漏洞的编译器版本中生成的代码中,run()将返回1。

在不了解该编译器漏洞的情况下,普通开发者很难通过简单的代码审查发现上述代码中存在的bug。这个示例代码比较简单,可能不会造成特别严重的危害。但如果b变量被用于权限验证、资产记账等用途,这种与预期的不一致可能导致十分严重的后果。

产生这种异常现象的原因在于,EVM使用栈式虚拟机,栈中每个元素均为32字节大小(即uint256变量大小)。另一方面,底层存储storage的每个slot也为32字节大小。而Solidity语言层面支持uint32等各类小于32字节的数据类型,编译器在处理这种类型的变量时,需要对其高位进行适当的清除操作(clean up)以保证数据的正确性。上述情况中,在加法产生整数溢出时,编译器没有正确地对结果高位进行clean up,导致溢出后高位的1 bit被写入storage中,最终覆盖了a变量后面的b变量,使b变量的值被修改成了1。

SOL-2022-4 InlineAssemblyMemorySideEffects

该漏洞存在于>=0.8.13 <0.8.15版本的编译器中。考虑如下代码:

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

Solidity编译器在将Solidity语言转换成EVM代码的过程中,不仅仅是简单的翻译。它还会进行深入的控制流与数据分析,实现各种编译优化流程,以缩减生成代码的体积,优化执行过程中的gas消耗。这类优化操作在各种高级语言的编译器中都很常见,但由于需要考虑的情况十分复杂,也很容易出现bug或安全漏洞。

上述代码的漏洞就源于这类优化操作。考虑这样一种情况:如果某个函数中存在修改内存0偏移处数据的代码,但后续没有任何地方使用该数据,那么实际上可以将修改内存0的代码直接移除,从而节约gas,并且不影响后续的程序逻辑。

这种优化策略本身并没有问题,但在具体的Solidity编译器代码实现中,此类优化只应用于单一的assembly block内。对上述示例代码,对内存0的写入和访问存在于两个不同的assembly block中,而编译器却只对单独的assembly block进行了分析优化。由于第一个assembly block中在写入内存0后没有任何读取操作,因此判定该写入指令是冗余的,会将该指令移除,从而产生bug。在存在漏洞的版本中,f()函数将返回值0,而实际上上述代码应该返回正确的值0x42。

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

该漏洞影响>= 0.5.8 < 0.8.16版本的编译器。考虑如下代码:

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

正常情况下,上述代码返回的a变量应为"aaaa"。但在存在漏洞的版本中会返回空字符串""。

该漏洞的成因是Solidity对calldata类型的数组进行abi.encode操作时,错误地对某些数据进行了clean up,导致修改了相邻的其他数据,造成了编码解码后的数据存在不一致。

值得注意的是,Solidity在进行external call和emit event时,会隐式地对参数进行abi.encode,因此上述漏洞代码出现的概率会比直观感觉更高。

安全建议

基于对Solidity编译器漏洞威胁模型的分析以及历史漏洞的梳理,对开发者和安全人员提出以下建议。

对开发者:

• 使用较新版本的Solidity编译器。尽管新版本也可能引入新的安全问题,但已知的安全问题通常较旧版本要少。

• 完善单元测试用例。大部分编译器层面的bug会导致代码执行结果与预期不一致。这类问题很难通过代码审查发现,但很容易在测试阶段暴露出来。因此通过提高代码覆盖率,可以最大程度地避免此类问题。

• 尽量避免使用内联汇编、针对多维数组和复杂结构体的abi编解码等复杂操作,没有明确需求时避免追求炫技而盲目使用语言新特性和实验性功能。根据历史漏洞的梳理,大部分漏洞与内联汇编、abi编码器等操作有关。编译器在处理复杂的语言特性时确实更容易出现bug。另一方面开发者在使用新特性时也容易出现使用上的误区,导致安全问题。

对安全人员:

• 在对Solidity代码进行安全审计时,不要忽视Solidity编译器可能引入的安全风险。在Smart Contract Weakness Classification(SWC)中对应的检查项为SWC-102: Outdated Compiler Version。

• 在内部SDL开发流程中,敦促开发团队升级Solidity编译器版本,并可以考虑在CI/CD流程中引入针对编译器版本的自动检查。

• 但对编译器漏洞无需过度恐慌,大部分编译器漏洞只在特定的代码模式下触发,并非使用有漏洞版本的编译器编译的合约就一定存在安全风险,实际的安全影响需要根据项目情况具体评估。

一些实用资源:

• Solidity团队定期发布的安全警报:

• Solidity官方仓库定期更新的bug列表:

• 各版本编译器bug列表:

• Etherscan上Contract -> Code页面右上角的三角形感叹号标志可提示当前版本编译器所存在的安全漏洞。

总结

本文从编译器的基本概念讲起,介绍了Solidity编译器漏洞,并分析了其在实际以太坊开发环境中可能导致的安全风险,最终对开发者和安全人员提供了若干实际的安全建议。