智能合約簽名驗(yàn)證漏洞分析你值得一看

可重入（Reentrancy）或整數(shù)溢出漏洞，是大多數(shù)開發(fā)人員知道或者至少聽說過的，關(guān)于智能合約當(dāng)中容易出現(xiàn)的安全問題。另一方面，在考慮智能合約的安全性時(shí)，你可能不會(huì)立即想到針對密碼簽名實(shí)現(xiàn)的攻擊方式。它們通常是與網(wǎng)絡(luò)協(xié)議相關(guān)聯(lián)的。例如，簽名重放攻擊（signature replay attacks），一個(gè)惡意用戶可竊聽包含有效簽名的協(xié)議序列，并針對目標(biāo)進(jìn)行重放攻擊，以期獲得益處。

本文將解釋智能合約處理DAPP生成簽名時(shí)可能存在的兩種類型的漏洞。我們將通過Diligence團(tuán)隊(duì)在今年早些時(shí)候完成的現(xiàn)實(shí)例子審計(jì)結(jié)果進(jìn)行分析。此外，我們將討論如何設(shè)計(jì)智能合約，以避免這類漏洞的出現(xiàn)。

協(xié)議層

簽名是以太坊網(wǎng)絡(luò)中的基礎(chǔ)，發(fā)送至網(wǎng)絡(luò)的每筆交易都必須具有有效的簽名。下圖顯示了這種交易的一個(gè)例子。除了交易標(biāo)準(zhǔn)屬性，例如 from、to、gas、value 或input在全局命名空間中可用，并且經(jīng)常出現(xiàn)在智能合約代碼中，字段v，r以及s共同組成了交易簽名。

以太坊網(wǎng)絡(luò)確保只有具有有效簽名的交易可被納入新的區(qū)塊當(dāng)中。這為交易提供了以下安全屬性：

1．身份驗(yàn)證：以太坊節(jié)點(diǎn)使用簽名來驗(yàn)證交易簽名者是否具有與公共地址相關(guān)聯(lián)的私鑰。開發(fā)者因此可以信任這個(gè)msg．sender是真實(shí)的；

2．完整性：交易在簽名后不會(huì)發(fā)生更改，否則簽名就是無效的；

3．不可否認(rèn)性：交易是由from字段中公共地址對應(yīng)的私鑰簽名的，這是不可否認(rèn)的，并且擁有私鑰的簽名方已經(jīng)進(jìn)行了任何狀態(tài)更改。

合約層

協(xié)議層并不是簽名發(fā)揮作用的唯一場地。簽名也越來越多地被用于智能合約本身。隨著gas價(jià)格的上漲，而擴(kuò)容解決方案仍在進(jìn)程當(dāng)中，則避免鏈上（on－chain）交易便凸顯出了越來越多的重要性。當(dāng)談到鏈外的交易時(shí)，簽名也是非常有用的，EIP－191以及EIP－712，都是有關(guān)于如何處理智能合約中簽名數(shù)據(jù)的通證標(biāo)準(zhǔn)。而后者旨在改善鏈外消息簽名的可用性。那么，為什么它是有用的，以及它是如何節(jié)省鏈上交易的？

讓我們來查看一個(gè)簡單的例子。愛麗絲為鮑伯創(chuàng)建了一個(gè)命題，她將其編碼成了一條消息。她還用自己的私鑰創(chuàng)建了消息的簽名，并通過協(xié)商好的通道發(fā)送給鮑伯。鮑伯可以驗(yàn)證愛麗絲是否簽署了該消息，如果鮑伯認(rèn)為該命題是合適的，那么他可以創(chuàng)建新的交易，將他自己的消息、愛麗絲的消息及簽名共同納入到一個(gè)智能合約當(dāng)中。通過數(shù)據(jù)，這個(gè)智能合約可以證實(shí)：

1．鮑伯已簽署了自己的信息（或者在這種情況下，交易會(huì)是更具體的）。而網(wǎng)絡(luò)保證了身份驗(yàn)證、完整性以及不可否認(rèn)性。

2．整個(gè)過程只需要一筆鏈上交易，其可提供明顯更好的用戶體驗(yàn)，同時(shí)可節(jié)省gas。需要注意的是，智能合約需要確保愛麗絲發(fā)送給鮑伯的消息，能夠保持所有三個(gè)安全屬性的完整性。

讓我們分析現(xiàn)實(shí)世界中存在的兩種簽名驗(yàn)證漏洞，并探討如何修復(fù)它們。

缺少針對簽名重放攻擊的保護(hù)（SWC－121）

第一個(gè)例子，是由Consensys的Diligence部門在審計(jì)去中心化新聞應(yīng)用Civil時(shí)發(fā)現(xiàn)的一個(gè)漏洞例子，與此案例相關(guān)的系統(tǒng)的第一部分，被Civil稱之為Newsroom（新聞編輯室），而內(nèi)容編輯可以把自己的文章發(fā)布到這個(gè)Newsroom，他們還可以為自己的內(nèi)存創(chuàng)作進(jìn)行加密簽名，以此證明內(nèi)容實(shí)際上是由他們創(chuàng)造的。pushRevision（） 函數(shù)對現(xiàn)有內(nèi)容進(jìn)行更新或修訂。參數(shù)內(nèi)容哈希、內(nèi)容URI、時(shí)間戳以及簽名，為內(nèi)容創(chuàng)建新的修訂。之后，verifiyRevisionSignature（）函數(shù)會(huì)調(diào)用提議修訂，以及最初創(chuàng)建第一個(gè)簽名修訂的內(nèi)容作者。根據(jù)設(shè)計(jì)，新修訂的簽署者，只能是創(chuàng)建初始簽名內(nèi)容版本的作者。

verifiyRevisionSignature（） 函數(shù)會(huì)根據(jù)DApp生成的內(nèi)容哈希，以及Newsroom合約的地址，創(chuàng)建一個(gè)已簽名的消息哈希。然后，調(diào)用recover（）函數(shù)（來自O(shè)penZeppelin 的ECRecovery庫）。隨后，調(diào)用ecrecover（）函數(shù)，并驗(yàn)證作者是否真正簽署了消息。已討論過的兩個(gè)函數(shù)代碼是沒有問題的，因?yàn)橹挥凶畛鮿?chuàng)建內(nèi)容的作者才能為它創(chuàng)建新的版本，所以實(shí)際上它們不存在什么安全問題。

問題在于，合約是不會(huì)跟蹤內(nèi)容哈希的，因此，已提交的一個(gè)內(nèi)容哈希及其用戶簽名，實(shí)際是有可能被提交多次的。而惡意的內(nèi)容作者就可以利用這個(gè)漏洞，從其他作者那里獲取有效的簽名和內(nèi)容哈希，并在他們不知情的情況下為他們創(chuàng)建新的有效修訂。

Civil 已通過跟蹤這些內(nèi)容哈希，并拒絕已是先前修訂部分的哈希，來解決這個(gè)問題。

缺乏正確的簽名驗(yàn)證（SWC－122）

在上一次審計(jì)去中心化協(xié)議0x的過程當(dāng)中，Diligence發(fā)現(xiàn)了這種漏洞類型的一個(gè)實(shí)例。以下解釋，是這次審計(jì)報(bào)告當(dāng)中3－2節(jié)內(nèi)容中描述的問題總結(jié)。0x協(xié)議具有不同簽名類型的各種簽名驗(yàn)證器，包括Web3以及EIP712。另一個(gè)存在的驗(yàn)證器稱為SignatureType．Caller，如果order．makerAddress等于msg．sender（order．makerAddress是創(chuàng)建order的用戶），則允許order有效。如果設(shè)置了SignatureType．Caller，則沒有實(shí)際簽名驗(yàn)證是由交易合約執(zhí)行的?，F(xiàn)在還不清楚為什么這會(huì)導(dǎo)致漏洞，因?yàn)橐呀?jīng)證實(shí)msg．sender以及order的創(chuàng)建者是相同的，至少從理論上看是這樣的。

除了交易合約之外，0x系統(tǒng)還有另一部分稱為Forwarder的合約，有了這個(gè)合約，用戶可以簡單地發(fā)送以太幣，以及他們想要填寫的 order，而這個(gè)Forwarder合約會(huì)在同一筆交易中執(zhí)行所有的order；

想要用以太幣交易其他通證的用戶，可以向其他用戶發(fā)送order，而Forwarder合約將代表他們進(jìn)行交易。這個(gè)交易合約會(huì)驗(yàn)證每個(gè)order，以確保order簽名的有效性，并確保其他用戶已實(shí)際簽署了order。讓我們再次查看上面的圖，并重新評估以下假設(shè)：如果order．makerAddress等于msg．sender，則我們不需要在這個(gè)交易合約當(dāng)中進(jìn)行適當(dāng)?shù)暮灻?yàn)證，因?yàn)榘l(fā)送交易的用戶也是order的創(chuàng)建者。如果用戶直接向交易合約發(fā)送order，則該假設(shè)成立。但是，如果我們通過Forwarder合約發(fā)送這個(gè)order，將order．makerAddress設(shè)置為 Forwarder合約的地址，并使用SignatureType．Caller簽名驗(yàn)證器呢？

在交易執(zhí)行處理結(jié)算個(gè)別order的過程中，F(xiàn)orwarder合約會(huì)調(diào)用這個(gè)交易合約。這個(gè)交易合約會(huì)驗(yàn)證這個(gè)order．makerAddress中的地址，就是msg．sender，在這種情況下，可以將其設(shè)置為Forwarder地址。由于合約在交易雙方之間起到了中介作用，所以order．takerAddress通常被設(shè)置為Forwarder地址。因此，惡意用戶可以使用Forwarder處理order，其中合約會(huì)與其本身進(jìn)行交易，因?yàn)樗仁墙邮苷哂质?u>制造者。這是因?yàn)橐韵碌脑颍?/p>

1．在 Forwarder當(dāng)中，沒有邏輯可以阻止合約成為一個(gè) order的制造者；

2．用于transferFrom（（address ＿from， address ＿to， uint256 ＿value） ）的ERC20規(guī)范，不會(huì)阻止用戶進(jìn)行“空傳輸”。而 ＿from和＿to可以是相同的地址；

3．這個(gè)交易合約允許基于以下事實(shí)來處理order：如果用戶實(shí)際上已經(jīng)簽署了order，則msg．sender沒有發(fā)送order。

在交易合約解決了order之后，這個(gè)Forwarder合約將得到完全相同的 balance，并且Forwarder合約將takerAmount轉(zhuǎn)移給自己，而把makerAmount轉(zhuǎn)移給一個(gè)惡意用戶，而惡意用戶可以使用這個(gè)場景，來創(chuàng)建“惡意order”，以便用1 Wei（以太幣最低單位）的價(jià)格從 Forwarder合約中換取到所有的ZRX通證；

綜上所述，假設(shè)消息的發(fā)送者也是其創(chuàng)建者，而不去驗(yàn)證其簽名，這可能是不安全的，尤其是在通過代理轉(zhuǎn)發(fā)交易的情況下。在合約處理消息簽名的任何時(shí)候，都需要執(zhí)行正確的簽名恢復(fù)及驗(yàn)證。0x通過刪除了 SignatureType．Caller簽名驗(yàn)證器修復(fù)了這個(gè)問題。

總結(jié)

鏈外消息簽名的方式，對于節(jié)省 gas以及改善用戶體驗(yàn)方面，的確是一個(gè)好的方法。但從安全性的角度來看，這無疑增加了復(fù)雜性，并使得智能合約在處理已簽名消息的情況下成為了一個(gè)更具挑戰(zhàn)性的任務(wù)。如果你對針對基于簽名的攻擊，或其它智能合約漏洞示例感興趣，你可以查看SWC－registry在Github的內(nèi)容，里面擁有大量易受攻擊的合約示例，此外還有關(guān)于智能合約弱點(diǎn)分類（SWC）計(jì)劃的更多信息，我們一直在與社會(huì)各界合作。如果你想了解更多關(guān)于SWC的信息，或者有其他好的想法，那么歡迎你在ethereum／EIPs以及Ethereum Magicians里面參加關(guān)于EIP－1470的討論；