針對區(qū)塊鏈安全問題，成都鏈安科技團隊每一周都將出智能合約安全漏洞解析連載，希望能幫助程序員寫出更加安全牢固的合約，防患于未然。

智能合約作為以太坊上各種加密數(shù)字貨幣的基礎(chǔ)，承載著巨大的經(jīng)濟利益。放眼以太坊的繁忙景象，日交易頻率在50-75萬次之間，而五月和二月更有兩日交易次數(shù)高達100萬次。合約的調(diào)用在整個以太坊生態(tài)系統(tǒng)猶如戰(zhàn)場上穿梭的子彈，不計其數(shù)。

可見其地位舉足輕重，功能五花八門，但萬變不離其宗的是，每個合約都有一個共性，會繼承一個地址對象，也就是說合約的基礎(chǔ)是地址。回顧前四期漏洞分析，我們了解攻擊者使出了渾身解數(shù)從合約的各個部分試圖不勞而獲，而從合約的地址漏洞入手，釜底抽薪自然也會成為攻擊手段之一。

下面我們就來聊聊，與地址有關(guān)的tx.origin變量和ecrecover（）函數(shù)的相關(guān)漏洞。

一言以蔽之

Solidity作為以太坊的官方語言，將地址定為20個字節(jié)，160位。所有合約都有一個地址對象，也可以對其他地址的代碼進行調(diào)用。地址類型的成員有我們上一期講到的call（）和delegatecall（），這兩個函數(shù)相關(guān)的漏洞請見右方鏈接：偷天換日合約易主，地址變臉移花接木 |成都鏈安漏洞分析連載第四期 —— 底層函數(shù)誤用漏洞。不同的合約地址代表了不同的合約，也代表了他們所擁有的權(quán)限。所以合約地址就相當(dāng)于合約的“身份證”。

本期相關(guān)兩個名詞專業(yè)的解釋是， tx.origin是Solidity的一個全局變量，它遍歷整個調(diào)用棧并返回最初發(fā)送調(diào)用（或事務(wù)）的帳戶的地址。ecrecover（）是內(nèi)嵌的函數(shù)，可以用來恢復(fù)簽名公鑰，傳值正確的情況下，可以利用這個函數(shù)來驗證地址。

通俗來說，tx.origin是整個交易過程最初的那個合約擁有者。當(dāng)這個合約A直接調(diào)用合約B的時候，擁有者也是中間人沒錯，都是合約A。

但是當(dāng)中間多出了一個合約C之后，合約A調(diào)用合約C，合約C調(diào)用合約B，這時中間人是C，但是tx.origin是合約A。

利用tx.origin的漏洞可以比喻為：

小明未滿十八歲，但對手中的游戲愛不釋手，但是游戲方為了限制未成年人的游戲時間，只有身份證號驗證已滿十八周歲的玩家才能無限制暢玩。于是小明使用長輩的身份證號進行防沉迷驗證。這樣，本來是游戲方對小明身份的驗證，變成了對其長輩身份的驗證，驗證結(jié)果予以通過，給予小明他不應(yīng)有的權(quán)限和利益。

至于ecrecover函數(shù)的問題，上面說到傳值正確的情況下，使用是沒有問題的，但普遍存在的問題是，傳值如果異常，沒有進行相應(yīng)的判定和排除。

我們來具體分析案例進行代碼層面的剖析。

深度分析

1. tx.origin使用錯誤

漏洞分析

tx.origin是Solidity的一個全局變量，它遍歷整個調(diào)用棧并返回最初發(fā)送調(diào)用（或事務(wù)）的帳戶的地址。在智能合約中使用此變量進行身份驗證會使合約容易受到類似網(wǎng)絡(luò)釣魚的攻擊。有關(guān)進一步閱讀，請參閱StackExchangeQuestion， PeterVenesses博客和Solidity-tx.origin攻擊。

對如下案例合約進行分析：

該合約有三個函數(shù)：constructor構(gòu)造函數(shù)，指定合約owner；fallback函數(shù)，通過添加payable關(guān)鍵字以便接收用戶轉(zhuǎn)賬；withdrawAll函數(shù)，對tx.origin進行判斷，如果tx.origin是owner，則將合約地址所擁有的ether發(fā)送到_recipient中。

現(xiàn)在，一個攻擊者創(chuàng)建了下列合約：

攻擊者誘使原合約（Phishable.sol）的owner發(fā)送ether到攻擊合約（POC.sol）地址，然后調(diào)用攻擊合約的fallback函數(shù)，執(zhí)行attack（）函數(shù)，此時phOwner == msg.sender，將會調(diào)用原合約的withdrawAll（）函數(shù)，程序執(zhí)行進入原合約，此時msg.sender是攻擊合約的地址，tx.origin是最初發(fā)起交易的地址，即原合約的owner，require（tx.origin == owner）;條件滿足，_recipient.transfer（this.balance）;可以執(zhí)行，即將原合約地址里的ether轉(zhuǎn)給攻擊者。

漏洞修復(fù)

tx.origin不應(yīng)該用于智能合約的授權(quán)。這并不是說永遠不應(yīng)該使用tx.origin變量。它在智能合約中確實有一些合法的用例。例如，如果想要拒絕外部合約調(diào)用當(dāng)前合約，他們可以通過require（tx.origin ==msg.sender）實現(xiàn)。 這可以防止使用中間合約來調(diào)用當(dāng)前合約。

2. ecrecover 未作0地址判斷

漏洞分析

keccak256（） 和 ecrecover（）都是內(nèi)嵌的函數(shù)， keccak256（） 可以用于計算公鑰的簽名， ecrecover（）可以用來恢復(fù)簽名公鑰。傳值正確的情況下，可以利用這兩個函數(shù)來驗證地址。

我們來看一個案例合約：

這個合約看似正常，但思索再三，如果ecrecover傳入錯誤參數(shù)（例如_v = 29，），函數(shù)返回0地址。如果合約函數(shù)傳入的校驗地址也為零地址，那么將通過斷言，導(dǎo)致合約邏輯錯誤。

函數(shù)transferProxy中，如果傳入的參數(shù)_from為0，那么ecrecover函數(shù)因為輸入?yún)?shù)錯誤而返回0值之后，if判斷將通過，從而導(dǎo)致合約漏洞［2］。

函數(shù) decode（）傳入經(jīng)過簽名后的數(shù)據(jù)，用于驗證返回地址是否是之前用于簽名的私鑰對應(yīng)的公鑰地址。以太坊提供了web3.eth.sign方法來對數(shù)據(jù)生成數(shù)字簽名。上面的簽名數(shù)據(jù)可以通過下面的js代碼獲得：

js代碼運行結(jié)果如下：

漏洞修復(fù)

對0x0地址做過濾，例如：

事關(guān)地址權(quán)限驗證，而且theDAO事件風(fēng)波未平（發(fā)生于6月17日），大量的討論者參與了進來。究竟應(yīng)不應(yīng)該停止使用這個變量呢？我們在漏洞修復(fù)的環(huán)節(jié)中已經(jīng)提到，如果想要拒絕外部合約調(diào)用當(dāng)前合約，可以通過require（tx.origin ==msg.sender）實現(xiàn)。

這可以防止使用中間合約來調(diào)用當(dāng)前合約，這可以防止外部函數(shù)調(diào)用時產(chǎn)生的風(fēng)險，我們在上一期已經(jīng)討論過相關(guān)的漏洞，詳情請見右方鏈接：偷天換日合約易主，地址變臉移花接木 |成都鏈安漏洞分析連載第四期 —— 底層函數(shù)誤用漏洞。

于是，有用戶新提出了一個使用tx.origin產(chǎn)生警告的建議。

官方警惕性非常高，及時處理了這個問題，于是這個漏洞暫時還沒有被利用于惡性攻擊的歷史事件。

那是不是可以說，這個漏洞并不重要呢？

目前合約的發(fā)展趨勢正在發(fā)生變化，重心漸漸向以太坊游戲傾斜。以太坊游戲以娛樂和休閑為外衣，對數(shù)字貨幣的交易進行了整合和包裝。但是游戲智能合約的漏洞依然層出不窮，不但有新型的非合約漏洞，而且還存在已經(jīng)報道出的一些漏洞。更有甚者，故意暴露出看似明顯的合約或機制缺陷，引誘投機倒把的玩家或者黑客，但暗中附加套路，玩起了“螳螂捕蟬黃雀在后”。

這種新型的詐騙合約我們稱為“蜜罐”。一些已知的缺陷通過黑客的修飾搖身一變，成為新型的騙局合約，例如近期有相關(guān)安全公司報道的名為QUESTION （中文含義：問題）的游戲合約，利用的是etherscan.io的缺陷，明修棧道，暗度陳倉，卷走玩家的錢財。

面幣思過

無論是地址驗證的欺騙，還是蜜罐合約的引誘，不懷好意的人總是瞄準(zhǔn)了深陷幣圈投資者的口袋。成都鏈安團隊提醒玩家和投資者們提高安全意識，以及對智能合約的了解程度，切不可盲目跟風(fēng)。我們從這個早期漏洞可以受到的啟發(fā)是，要辨析一些容易混淆的原理之后，才能認(rèn)清某些不易察覺的陷阱和漏洞，提高警惕，理智投資，穩(wěn)健操作，會當(dāng)凌絕頂，一覽眾山小。