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

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

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

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

一言以蔽之

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

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

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

但是當中間多出了一個合約C之后，合約A調用合約C，合約C調用合約B，這時中間人是C，但是tx.origin是合約A。

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

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

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

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

深度分析

1. tx.origin使用錯誤

漏洞分析

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

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

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

現在，一個攻擊者創建了下列合約：

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

漏洞修復

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

2. ecrecover 未作0地址判斷

漏洞分析

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

我們來看一個案例合約：

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

函數transferProxy中，如果傳入的參數_from為0，那么ecrecover函數因為輸入參數錯誤而返回0值之后，if判斷將通過，從而導致合約漏洞［2］。

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

js代碼運行結果如下：

漏洞修復

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

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

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

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

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

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

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

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

面幣思過

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