Lines of code

Vulnerability details

Impact

Missing ReEntrancy Guard to Withdraw function

Proof of Concept

There is no re-entry risk on true ERC-20 tokens that work according to the spec (i.e. audited, etc.).

However you can write a malicious ERC-20 with custom transferFrom() or approve() that have re-entrancy hooks to attack a target.

Furthermore ERC-777 is backwards compatible token standard with ERC-20 standard. ERC-777 has better usability, but it has transfer hooks that can cause re-entrancy.

Project developers have mentioned Reentrancy with the information below. However, to prevent Reentrancy, only the Checks-effects-interaction pattern is not enough.

VTVLVesting.sol#L385
         // After the "books" are set, transfer the tokens
         // Reentrancy note - internal vars have been changed by now
         // Also following Checks-effects-interactions pattern

openzeppelin’s view on the reentrancy problem

ERC20 generally doesn’t result in reentrancy, however ERC777 tokens can and they can maskerade as ERC20. So if a contract interacts with unknown ERC20 tokens it is better to be safe and consider that transfers can create reentrancy problems.

Although reentrancy attack is considered quite old over the past two years, there have been cases such as:

• Uniswap/LendfMe hacks (2020) ($25 mln, attacked by a hacker using a reentrancy)

• The BurgerSwap hack (May 2021) ( $7.2 million because of a fake token contract and a reentrancy exploit.)

• The SURGEBNB hack (August 2021) ($4 million seems to be a reentrancy-based price manipulation attack.)

• CREAM FINANCE hack (August 2021) ($18.8 million, reentrancy vulnerability allowed the exploiter for the second borrow.)

• Siren protocol hack (September 2021) ($3.5 million, AMM pools were exploited through reentrancy attack.)

Type of Reentrancy

Details
1 - Single Function Reentrancy
2 - Cross-Function Reentrancy
3 - Cross-Contract Reentrancy

Tools Used

Manuel code review

Recommended Mitigation Steps

Use Openzeppelin or Solmate Re-Entrancy pattern

Here is a example of a re-entracy guard

// 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;
    }
}  

---

The text was updated successfully, but these errors were encountered:

All reactions