智能合約有什么錯(cuò)誤的算法

這篇博客文章是該系列文章的第二篇，將講述一些簡單的現(xiàn)實(shí)中智能合約安全性Bug，黑客們是如何利用它們造成系統(tǒng)的影響以及提供相應(yīng)的修復(fù)代碼。到目前為止，我們已經(jīng)實(shí)現(xiàn)了3，000萬美元的修復(fù)挽救，即直接歸因于智能合約安全漏洞的2.5億美元的損失。這次我們將分別存入兩筆存款，分別為：57，896，044，618，658，097，711，785，492，504，343，953，926，634，992，332，820，282，019，728，792，003，956，564，819，968個(gè)代幣，總計(jì)0個(gè)代幣！

這篇博客文章將專門介紹算術(shù)運(yùn)算的Bug（例如整數(shù)溢出）盡管智能合約提供了具有獨(dú)特新穎性的執(zhí)行環(huán)境，但這無疑不是一個(gè)新問題。算法的Bug幾乎占據(jù)了SEI CERT Oracle Java編碼標(biāo)準(zhǔn)中大部分的吸引力。其他開發(fā)語言也遭受完全相同的可怕情況，漏洞映射到幾個(gè)常見的Bug中。智能合約主要面臨與公共執(zhí)行環(huán)境的安全，不可變更的性質(zhì)，不同的利益相關(guān)者類別以及邏輯復(fù)雜性相關(guān)的獨(dú)特挑戰(zhàn)。

讓我們看一下BeautyChainToken的合約代碼，該代碼可以在Etherscan上可以輕松找到。通過瀏覽代碼可以發(fā)現(xiàn)在最頂部附近有一個(gè)名為SafeMath的庫的實(shí)現(xiàn)，隨后是一系列相互依存的合約。忽略周圍其他的代碼干擾，但請注意經(jīng)常引用變量to，from，amount和balances以及稱為transfer（）和approve（）的函數(shù)，這是一個(gè)不到300行的全功能代碼。

讓我們從第255行開始檢查batchTransfer（）函數(shù)。它有兩個(gè)參數(shù)-第一個(gè)參數(shù)（_receivers）是目標(biāo)帳戶地址的列表，第二個(gè)參數(shù)（_value）是要轉(zhuǎn)移到每個(gè)目標(biāo)帳戶地址的代幣數(shù)。第256行計(jì)算列表中接收方地址的數(shù)量，然后第257行可以計(jì)算從發(fā)送方帳戶余額中提取的總金額。第259行確保發(fā)送方有足夠的余額，然后第261將第257行向下調(diào)整之前的總金額。最后第262行開始循環(huán)，通過將每個(gè)接收者的余額向上調(diào)整_value來執(zhí)行單獨(dú)的轉(zhuǎn)帳。

255 function batchTransfer（address［］ _receivers， uint256 _value） public whenNotPaused returns （bool） {

256 uint cnt = _receivers.length;

257 uint256 amount = uint256（cnt） * _value;

258 require（cnt 》 0 && cnt 《= 20）;

259 require（_value 》 0 && balances［msg.sender］ 》= amount）;

260

261 balances［msg.sender］ = balances［msg.sender］.sub（amount）;

262 for （uint i = 0; i 《 cnt; i++） {

263 balances［_receivers［i］］ = balances［_receivers［i］］.add（_value）;

264 Transfer（msg.sender， _receivers［i］， _value）;

265 }

266 return true;

267 }

Solidity中最常見的數(shù)據(jù)類型之一是unsign256位整數(shù)（uint256或uint），它可以表示0到2^256-1之間的任何值。如果合約代碼執(zhí)行一個(gè)普通的算術(shù)運(yùn)算，得到的結(jié)果超出了這個(gè)范圍，則結(jié)果會悄悄地被包裝起來，合約也將會繼續(xù)使用錯(cuò)誤的數(shù)據(jù)，這是非?？膳碌慕Y(jié)果。出于這個(gè)原因，上面顯示的合約特別是使用了前面看到的safemath庫中的專用的.sub（）和.add（）函數(shù)（分別位于第261行和第263行）。如果遇到下溢或上溢，將編寫這些通用函數(shù)來中止操作，這將阻止執(zhí)行繼續(xù)處理不良數(shù)據(jù)。您可能會問為什么第257行使用普通的‘*’而不是SafeMath中的.mul（）。

Bug！關(guān)于第257行，如果_value設(shè)置為2^255，然后由于在前一行計(jì)算出的cnt為2而加倍，則由于回繞（wrap-around）效應(yīng)，結(jié)果將被存儲進(jìn)amount為0（而不是2^256）。這是我們旨在解決的確切錯(cuò)誤-現(xiàn)在將繼續(xù)處理錯(cuò)誤數(shù)據(jù)，繼續(xù)執(zhí)行。要求的_value很大，但總計(jì)算amount為0！amount為0金額時(shí)余額檢查將會被忽略第259行，并繼續(xù)通過第261行上的進(jìn)行余額調(diào)。然而在執(zhí)行單個(gè)傳輸?shù)难h(huán)利用了巨大的_value變量（不再引用數(shù)量變量）。這意味著循環(huán)將使兩個(gè)目標(biāo)余額分別增加2^255。累積增加！

發(fā)生了什么？攻擊者調(diào)用了上面所示的batchTransfer（）函數(shù)，并為其提供了一個(gè)_receivers列表，該列表包含兩個(gè)地址和一個(gè)_value參數(shù)設(shè)置為2^255。在Etherscan事務(wù)中可以清楚地看到這一點(diǎn)（單擊“解碼輸入數(shù)據(jù)”）。如前所述，地址的cnt計(jì)算為2，因此乘以2^255的值將導(dǎo)致溢出到0。此錯(cuò)誤數(shù)據(jù)將繼續(xù)執(zhí)行。通過各種參數(shù)檢查，發(fā)件人的余額減少到0，最后將_value的兩筆存款存入_receivers余額。順便說一句，如果您還沒有猜到的話，本帖子第一段中提到的大量數(shù)字恰好是2^255。大約0.02美元的真金白銀來資助攻擊交易，兩筆大量的代幣是憑空創(chuàng)建的，并存放到_receiver地址中。這導(dǎo)致了對該代幣合約的信任喪失，從而徹底破壞了其價(jià)值。

讓我們修復(fù)它。我們要做的就是用.mul（）替換第257行上的普通“ *”，如下所示。前綴為“ –”的行將從合約代碼中刪除，而前綴為“ +”的行將被添加。

- uint256 amount = uint256（cnt） * _value;

+ uint256 amount = uint256（cnt）.mul（_value）;

回想起來很簡單嗎？回看一下過去Bug，幾乎所有安全Bug都變得非常明顯，但二十多年來，開發(fā)人員一直在犯這些相同的錯(cuò)誤。請注意，上述修復(fù)代碼對于BeautyChainToken來說是沒有意義的，因?yàn)橹悄芎霞s的軟件沒有更新。一旦部署了智能合約，它們除原始代碼之外就基本上不可更改且不可阻擋。因此，我們非常簡單的解決方案（僅由幾個(gè)字符組成）只能成為未來的一個(gè)教訓(xùn)，強(qiáng)調(diào)了“不要讓算術(shù)結(jié)果出錯(cuò)，然后繼續(xù)使用錯(cuò)誤數(shù)據(jù)執(zhí)行”。

沒那么簡單。代幣是智能合約的一個(gè)用例之一，都是由頂級專家進(jìn)行非常謹(jǐn)慎的開發(fā)。SafeMath庫的存在表明這是一個(gè)已知的問題區(qū)域，但是我們上面看到的代碼確實(shí)使用了SafeMath庫。實(shí)際上，ERC-20代幣標(biāo)準(zhǔn)本身就有幾個(gè)已知的問題，這些問題僅能部分解決（最好）。