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編譯器漏洞,分析了其在實際以太坊開發環境中可能導致的安全風險,並爲開發者和安全人員提供了一些實際的安全建議。通過了解和重視編譯器漏洞,可以更全面地保障智能合約的安全性。