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

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

虽然大多数开发者和安全人员通常更关注应用程序代码的安全性,但编译器本身的安全性同样重要。作为计算机程序,编译器也可能存在安全漏洞,在某些情况下会带来严重的安全风险。例如,浏览器在编译和解析执行JavaScript前端代码时,可能因JavaScript解析引擎的漏洞而导致用户在访问恶意网页时被攻击者利用,最终实现对受害者浏览器甚至操作系统的控制。

Solidity编译器同样存在安全漏洞。根据Solidity开发团队的安全警告,多个不同版本的Solidity编译器中都发现了安全问题。

Solidity编译器漏洞

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

需要注意的是,Solidity编译器漏洞与EVM自身漏洞是不同的。EVM漏洞指虚拟机在执行指令时产生的安全问题。由于攻击者可以上传任意代码到以太坊,如果EVM存在安全漏洞,将影响整个以太坊网络,可能导致拒绝服务(DoS)甚至整个区块链被攻击者接管。不过,EVM设计相对简单,核心代码更新不频繁,因此出现此类问题的可能性较低。

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

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

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

Solidity编译器漏洞示例

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

SOL-2016-9 HighOrderByteCleanStorage

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

考虑以下代码:

solidity contract C { uint32 a = 0x12345678; uint32 b = 0; function f() public { a = 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。对上述PoC代码,对内存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(string[1] calldata a) public pure returns (string memory) { return abi.decode(abi.encode(a), (string[1]))[0]; } }

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

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

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

安全建议

针对Solidity编译器漏洞的威胁,对开发者和安全人员提出以下建议:

对开发者:

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

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

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

对安全人员:

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

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

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

一些实用资源:

• Solidity Team定期发布的Security Alerts posts
• Solidity官方repo定期更新的bug list
• 各版本编译器bug列表。可在CI/CD过程中引入自动进行编译器版本的检查,提示当前版本中存在的安全漏洞。
• Etherscan上Contract -> Code页面右上角的三角形感叹号标志可提示当前版本编译器所存在的安全漏洞。

总结

本文从编译器的基本概念出发,介绍了Solidity编译器漏洞,分析了其在实际以太坊开发环境中可能导致的安全风险,并为开发者和安全人员提供了一些实际的安全建议。通过了解和重视编译器漏洞,可以更全面地保障智能合约的安全性。