摘要：今天，我們繼續(xù)介紹文獻(xiàn)中提到的以太坊合約的安全性弱點(diǎn)與案例。隨機(jī)數(shù)生成的字節(jié)碼執(zhí)行是確定性的。但是，一個(gè)惡意的礦工可能嘗試操縱自己生成的區(qū)塊來(lái)影響隨機(jī)數(shù)的生成與合約的執(zhí)行結(jié)果。合約中的錢將被偷走。

今天，我們繼續(xù)介紹文獻(xiàn)中提到的以太坊合約的安全性弱點(diǎn)與案例。

數(shù)據(jù)保密
Solidity 智能合約中的變量分 public 和 private 兩種。Private 變量表示這個(gè)數(shù)值不能被其他合約直接讀取。

但是，將一個(gè)變量標(biāo)記為 private 不意味著里面的信息就是保密的。因?yàn)橐蕴皇枪_(kāi)的，每次合約函數(shù)執(zhí)行的字節(jié)碼，參數(shù)都是公開(kāi)的，任何人都可以推斷出每次函數(shù)執(zhí)行后是否修改了變量，修改后的數(shù)值是多少。Private 只是能夠保證其他合約執(zhí)行的時(shí)候，無(wú)法讀取其中的變量罷了。

然而，一些本應(yīng)該隱藏玩家數(shù)據(jù)的游戲，卻錯(cuò)誤地使用了這一點(diǎn)。以下是一個(gè)示例：

兩個(gè)玩家在玩一個(gè)賭博游戲，每個(gè)玩家選一個(gè)正整數(shù)，兩個(gè)正整數(shù)加起來(lái)的奇偶性，決定了獲勝者。

存儲(chǔ)玩家選擇的變量是 players, 這個(gè)變量具有 private 屬性。玩家通過(guò)調(diào)用智能合約函數(shù)選數(shù)的時(shí)候，決策并不是保密的。

為了實(shí)現(xiàn)保密性，更好的方式是使用一個(gè)稱為“委托”的密碼學(xué)原語(yǔ)。當(dāng)玩家需要秘密地做出一個(gè)決定時(shí)，可以將 sha3(決策內(nèi)容,隨機(jī)數(shù)) 得到的哈希值存到合約里。當(dāng)玩家需要公開(kāi)自己選擇的時(shí)候，將 決策內(nèi)容 與 隨機(jī)數(shù) 公開(kāi)，并由智能合約驗(yàn)證哈希值與先前存儲(chǔ)的是否一致?？梢詫?shí)現(xiàn)類似于“先在紙上秘密寫下選擇，到后面一個(gè)環(huán)節(jié)再亮出來(lái)”的功能。

隨機(jī)數(shù)生成
EVM 的字節(jié)碼執(zhí)行是確定性的。因此，如果智能合約想生成一個(gè)隨機(jī)數(shù)，就需要通過(guò)一個(gè)隨機(jī)數(shù)種子生成一個(gè)偽隨機(jī)數(shù)。而隨機(jī)數(shù)種子的選取方式，對(duì)生成隨機(jī)數(shù)的公平性有很大的影響。

一個(gè)常用的做法是，使用一個(gè)給定時(shí)間或給定高度區(qū)塊的哈希值或時(shí)間戳。這件事情在給定區(qū)塊被確認(rèn)以后，在每個(gè)礦工看來(lái)都是一樣的。

看起來(lái)這是一個(gè)公平的做法，因?yàn)闆](méi)有人能預(yù)測(cè)未來(lái)的區(qū)塊。但是，一個(gè)惡意的礦工可能嘗試操縱自己生成的區(qū)塊來(lái)影響隨機(jī)數(shù)的生成與合約的執(zhí)行結(jié)果。一個(gè)分析表示，一個(gè)控制少數(shù)算力的礦工，只需要投入 50 個(gè)比特幣就可以顯著地改變輸出結(jié)果的概率分布。

另一個(gè)方式是使用“延時(shí)委托協(xié)議”。在這個(gè)協(xié)議中，每個(gè)參與者選擇一個(gè)秘密的隨機(jī)數(shù)，并將哈希值廣播給其他人。在晚些時(shí)候，所有參與者公布它們選取的秘密隨機(jī)數(shù)，或者丟失押金。最終隨機(jī)數(shù)由所有公布的秘密隨機(jī)數(shù)和一個(gè)公開(kāi)的算法生成。攻擊者可以在“其他所有人都已經(jīng)公布了隨機(jī)數(shù)，自己還沒(méi)有公布”時(shí)，預(yù)先計(jì)算最終生成的隨機(jī)數(shù)，如果生成的結(jié)果它不滿意，就通過(guò)拒絕公布自己選擇的隨機(jī)數(shù)方式，來(lái)使這個(gè)結(jié)果無(wú)效。當(dāng)然，攻擊者要損失一些押金。所以，押金的設(shè)定要足夠高，高于隨機(jī)數(shù)生成中改變結(jié)果可能帶來(lái)的收益。

不可預(yù)測(cè)狀態(tài)
一個(gè)合約的狀態(tài)包括合約變量和合約余額。一般情況下，當(dāng)用戶通過(guò)一筆交易調(diào)用合約函數(shù)的時(shí)候，從交易廣播到交易被加入?yún)^(qū)塊之間，可能有其他的交易改變了合約的狀態(tài)。也就是說(shuō)，當(dāng)用戶發(fā)起一筆交易時(shí)，并不能確定這筆交易被執(zhí)行時(shí)，合約的狀態(tài)是什么。

一個(gè)基于 library 和不可預(yù)測(cè)狀態(tài)的攻擊
下面我們來(lái)看一個(gè)例子，以下的 Solidity 代碼定義了一個(gè)名為 Set 的 library。

下面是一個(gè)名為 SetProvider 的合約，提供了一個(gè) Set library 的地址，合約擁有者可以修改這個(gè)地址，任何人/合約可以獲取這個(gè)地址。

假設(shè) Bob 合約是一個(gè)使用 SetProvider 的誠(chéng)實(shí)用戶，他的代碼如下：

Bob 記錄了一個(gè) SetProvider 合約的地址，在 getSetVersion() 中，使用這個(gè)地址獲取了一個(gè) Set library 的版本號(hào)。

現(xiàn)在，假設(shè) SetProvider 合約的控制者是個(gè)壞人。他制造了一個(gè)惡意的 Set library, 希望偷得一些錢存到他自己的錢包地址 0x42 中。

如果合約 SetProvider 中 setLibAddr 的地址被修改為 MaliciousSet 的地址， Bob 合約中調(diào)用 getSetVersion() 函數(shù)時(shí)，會(huì)調(diào)用 MaliciousSet 的 version() 函數(shù)，而不是 Set 的。因?yàn)?Bob 合約中將 Set 聲明為一個(gè) library, 所以對(duì) version() 的調(diào)用采用的是 delegatecall 模式。 delegatecall 模式意味著轉(zhuǎn)賬操作 attackerAddr.send(this.balance); 是從 Bob 合約中轉(zhuǎn)賬出來(lái)。 Bob 合約中的錢將被偷走。

上述例子說(shuō)明了，對(duì) library 函數(shù)的調(diào)用使用的是較為危險(xiǎn)的 delegatecall 模式。因此合約編寫者在使用其他合約地址作為 library 時(shí)，一定要保證通過(guò) library 加載進(jìn)來(lái)的代碼是自己可控的。比如，手動(dòng)指定一個(gè)已經(jīng)在區(qū)塊鏈上不可修改的 library 的地址。而不是在本例中依靠于一個(gè)不可靠的 SetProvider 合約來(lái)獲取 library 的地址。

另外，“不可預(yù)測(cè)狀態(tài)”問(wèn)題也加劇了這件事情。即使在調(diào)用 Bob 合約的 getSetVersion() 函數(shù)時(shí)， SetProvider 指向的是誠(chéng)實(shí)的 Set library. 攻擊者也可以在這一交易還沒(méi)有被加入?yún)^(qū)塊的時(shí)候，通過(guò)發(fā)起一筆交易費(fèi)數(shù)額較大的交易，搶在 getSetVersion() 被加入?yún)^(qū)塊之前，將 SetProvider 的指向修改為 MaliciousSet。

Conflux 是致力于打造下一代高性能的 DAPP 公鏈平臺(tái)

歡迎關(guān)注我們的微信公眾號(hào)：Conflux中文社區(qū)(Conflux-Chain)

添加微信群管理員 Confluxgroup 回復(fù)“加群”加入 Conflux官方交流群