SOL:Solidity編譯器漏洞分析：ABI重編碼的缺陷-ODAILY

總覽

本文從源代碼層面對Solidity編譯器(0.5.8<=version<0.8.16)在ABIReencoding過程中，由于對固定長度的uint和bytes32類型數組的錯誤處理所導致的漏洞問題進行詳細分析，并提出相關的解決方案及規避措施。

漏洞詳情

ABI編碼格式是用在用戶或合約對合約進行函數調用，傳遞參數時的標準編碼方式。具體可以參考Solidity官方關于ABI編碼的詳細表述。

在合約開發過程中，會從用戶或其他合約傳來的calldata數據中，獲取需要的數據，之后可能會將獲取的數據進行轉發或emit等操作。限于evm虛擬機的所有opcode操作都是基于memory、stack和storage，所以在Solidity中，涉及到需要對數據進行ABI編碼的操作，都會將calldata中的數據根據新的順序按照ABI格式進行編碼，并存儲到memory中。

該過程本身并沒有大的邏輯問題，但是當和Solidity的cleanup機制結合時，由于Solidity編譯器代碼本身的疏漏，就導致了漏洞的存在。

根據ABI編碼規則，在去掉函數選擇符之后，ABI編碼的數據分為head和tail兩部分。當數據格式為固定長度的uint或bytes32數組時，ABI會將該類型的數據都存儲在head部分。而Solidity對memory中cleanup機制的實現是在當前索引的內存被使用后，將下一個索引的內存置空，以防止下一索引的內存使用時被臟數據影響。并且，當Solidity對一組參數數據進行ABI編碼時，是按照從左到右的順序進行編碼！！

Solana基金會將于2023年10月30日開始舉辦Solana生態會議:金色財經報道，Solana 基金會宣布將于2023年10 月 30 日至 11 月 3 日在阿姆斯特丹舉辦 Solana 生態系統的旗艦會議。[2023/5/16 15:06:49]

為了便于后面的漏洞原理探索，考慮如下形式的合約代碼：

contractEocene{

eventVerifyABI(bytes,uint);

functionverifyABI(bytescalldataa,uintcalldatab)public{

emitVerifyABI(a,b);//Event數據會按照ABI格式編碼之后存儲到鏈上

}

}

合約Eocene中verifyABI函數的作用，僅僅是將函數參數中的不定長bytesa和定長uintb進行emit。

這里需要注意，event事件也會觸發ABI編碼。這里參數a,b會編碼成ABI格式后再存儲到鏈上。

我們使用v0.8.14版本的Solidity對合約代碼進行編譯，通過remix進行部署，并傳入verifyABI(,)。

首先，我們看一看對verifyABI(,)的正確編碼格式：

0x52cd1a9c//bytes4(sha3("verify(btyes,uint)"))

6月Solana鏈上NFT銷售量近170萬筆，創2021年8月以來最高記錄:金色財經報道，據cryptoslam數據顯示，在剛剛過去的6月中，Solana鏈上NFT銷售額僅為1.03億美元，創過去11個月以來的最低紀錄。自2021年8月以來，Solana鏈上NFT銷售額最高記錄發生在今年一月，當時交易額為299,419,009.15美元。不過，6月Solana鏈上NFT銷售量卻達到1,697,912筆，創下自2021年8月以來的最高紀錄，此外5月Solana鏈上NFT銷售額為1,227,362筆，創過去11個月以來第二高交易量記錄。[2022/7/2 1:45:51]

0000000000000000000000000000000000000000000000000000000000000060//indexofa

0000000000000000000000000000000000000000000000000000000000011111//b

0000000000000000000000000000000000000000000000000000000000022222//b

0000000000000000000000000000000000000000000000000000000000000002//lengthofa

0000000000000000000000000000000000000000000000000000000000000040//indexofa

Solana永續期貨DEX Drift 24小時交易量達3.6億美元:5月11日消息，Solana生態永續期貨DEX Drift Protocol 24小時交易量達3.6億美元，創下歷史新高（ATH）。[2022/5/11 3:06:20]

0000000000000000000000000000000000000000000000000000000000000080//indexofa

0000000000000000000000000000000000000000000000000000000000000003//lengthofa

aaaaaa0000000000000000000000000000000000000000000000000000000000//a

0000000000000000000000000000000000000000000000000000000000000003//lengthofa

bbbbbb0000000000000000000000000000000000000000000000000000000000//a

如果Solidity編譯器正常，當參數a,b被event事件記錄到鏈上時，數據格式應該和我們發送的一樣。讓我們實際調用合約試試看，并對鏈上的log進行查看,如果想自己對比，可以查看該TX。

成功調用后，合約event事件記錄如下：

跨鏈協議Soluna宣布開啟solUST質押:3月1日消息，跨鏈協議 Soluna 宣布開啟 solUST 質押，用戶可通過 crate 協議將 solUST 參與者將 solUST 進行存放，參與者將直接獲得一定比例的 Anchor（Terra 儲蓄協議）網絡收益。

此前報道，2 月 10 日，Solana 鏈上去中心化交易平臺 Saber 宣布推出 Soluna 跨鏈協議，并在 Solana 上推出首個 solUST-UST(Wormhole) 池。該功能允許任何人將存放在 Anchor（Terra 儲蓄協議）上的有息資產發送到 Solana。[2022/3/1 13:29:45]

！！震驚，緊跟b的，存儲a參數長度的值被錯誤的刪除了！！

0000000000000000000000000000000000000000000000000000000000000060//indexofa

0000000000000000000000000000000000000000000000000000000000011111//b

0000000000000000000000000000000000000000000000000000000000022222//b

0000000000000000000000000000000000000000000000000000000000000000//lengthofa??whybecome0??

Solana Labs聯合創始人：Solana無意也無法扼殺以太坊:11月12日消息，雖然由于Solana（SOL）費用更低、交易更快，許多專家將其稱為“以太坊殺手”，但Solana Labs聯合創始人Raj Gokal表示，Solana無意扼殺以太坊——而且就算真的這么做了，也無法實現。Gokal近日在推特上回應風險投資公司Placeholder聯合創始人Chris Burniske時強調“這并不一定是一場戰斗“，因為他認為所有從事加密領域工作的人的目標應該是讓“每個人”都能進入Web 3.0，并指出：“我們并未試圖扼殺以太坊。以太坊不會被扼殺，這是不可能的。它已經是世界上一種美麗的善之力量，賦予數百萬人權力，并創造數十億的財富，比特幣顯然也是如此。”（Cointelegraph）[2021/11/12 21:45:37]

0000000000000000000000000000000000000000000000000000000000000040//indexofa

0000000000000000000000000000000000000000000000000000000000000080//indexofa

0000000000000000000000000000000000000000000000000000000000000003//lengthofa

aaaaaa0000000000000000000000000000000000000000000000000000000000//a

0000000000000000000000000000000000000000000000000000000000000003//lengthofa

bbbbbb0000000000000000000000000000000000000000000000000000000000//a

為什么會這樣？

正如我們前面所說，在Solidity遇到需要進行ABI編碼的系列參數時，參數的生成順序是從左至，具體對a,b的編碼邏輯如下

Solidity先對a進行ABI編碼，按照編碼規則，a的索引放在頭部，a的元素長度以及元素具體值均存放在尾部。

處理b數據，因為b數據類型為uint格式，所以數據具體值被存放在head部分。但是，由于Solidity自身的cleanup機制，在內存中存放了b之后，將b數據所在的后一個內存地址(被用于存放a元素長度的內存地址)的值置0。

ABI編碼操作結束，錯誤編碼的數據存儲到了鏈上，SOL-2022-6漏洞出現。

在源代碼層面，具體的錯誤邏輯也很明顯，當需要從calldata獲取定長bytes32或uint數組數據到memory中時，Solidity總是會在數據復制完畢后，將后一個內存索引數據置為0。又由于ABI編碼存在head和tail兩部分，且編碼順序也是從左至右，就導致了漏洞的存在。

具體漏洞的Solidity編譯代碼如下：

當源數據存儲位置為Calldata，且源數據類型為ByteArray，String，或者源數組基礎類型為uint或bytes32時進入ABIFunctions::abiEncodingFunctionCalldataArrayWithoutCleanup()

進入之后，會首先通過fromArrayType.isDynamicallySized()對源數據是否為定長數組來對源數據進行判斷，只有定長數組才符合漏洞觸發條件。

將isByteArrayOrString()判斷結果傳遞給YulUtilFunctions::copyToMemoryFunction(),根據判斷結果來確定是否在calldatacopy操作完成后，對后一個索引位置進行cleanup。

上訴幾個約束條件結合，就只有位于calldata中的源數據格式為定長的uint或bytes32的數組復制到內存時才能觸發漏洞。也即是漏洞觸發的約束條件產生的原因。

由于ABI進行參數編碼時，總是從左到右的順序，考慮到漏洞的利用條件，我們必須要明白，必須在定長的uint和bytes32數組前，存在動態長度類型的數據被存儲到ABI編碼格式的tail部分，且定長的uint或bytes32數組必須位于待編碼參數的最后一個位置。

原因很明顯，如果定長的數據沒有位于最后一個待編碼參數位置，那么對后一內存位置的置0不會有任何影響，因為下個編碼參數會覆蓋該位置。如果定長數據前面沒有數據需要被存儲到tail部分，那么即便后一內存位置被置0也沒有關系，因為該位置并不背ABI編碼使用。

另外，需要注意的是，所有的隱式或顯示的ABI操作，以及符合格式的所有Tuple，都會受到該漏洞的影響。

具體的涉及到的操作如下：

event

error

abi.encode*

returns//thereturnoffunction

struct//theuserdefinedstruct

allexternalcall

解決方案

當合約代碼中存在上訴受影響的操作時，保證最后一個參數不為定長的uint或bytes32數組

使用不受漏洞影響的Solidity編譯器

尋求專業的安全人員的幫助，對合約進行專業的安全審計

關于我們

AtEoceneResearch,weprovidetheinsightsofintentionsandsecuritybehindeverythingyouknowordon'tknowofblockchain,andempowereveryindividualandorganizationtoanswercomplexquestionswehadn'tevendreamedofbackthen.

Learnmore:Website|Medium|Twitter

Tags：SOLLANAOLASolanaMSOLsolana幣官網下載appDOLAsolana幣怎么挖礦

AVAX