apegurus/reentrancy

<!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) --> <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->

Reentrancy Exploits

Overview

Reentrancy occurs when an external call allows the callee to re-enter the calling function before state updates complete.

Types:

1. Classic reentrancy - Same function called again
2. Cross-function - Different function in same contract
3. Cross-contract - Function in different contract sharing state
4. Read-only - View function returns stale state during reentrancy

---

The DAO Hack (2016)

Loss: ~$60M (3.6M ETH) Root Cause: Classic reentrancy

Vulnerable Code

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    
    // External call BEFORE state update
    (bool success,) = msg.sender.call{value: _amount}("");
    require(success);
    
    // State update AFTER - never reached during reentrancy
    balances[msg.sender] -= _amount;
}

Attack

contract Attacker {
    DAO dao;
    
    function attack() external payable {
        dao.deposit{value: 1 ether}();
        dao.withdraw(1 ether);
    }
    
    receive() external payable {
        if (address(dao).balance >= 1 ether) {
            dao.withdraw(1 ether);  // Re-enter before balance update
        }
    }
}

Fix: CEI Pattern

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    
    balances[msg.sender] -= _amount;  // State update FIRST
    
    (bool success,) = msg.sender.call{value: _amount}("");
    require(success);
}

---

Cream Finance (2021)

Loss: ~$130M Root Cause: Cross-contract reentrancy via AMP token (ERC777)

Vulnerable Pattern

// Cream's borrow function
function borrow(uint amount) external {
    // Check collateral
    require(getAccountLiquidity(msg.sender) >= amount);
    
    // Transfer tokens (ERC777 calls receiver hook)
    token.transfer(msg.sender, amount);  // REENTRANCY HERE
    
    // Update borrow balance
    borrowBalances[msg.sender] += amount;
}

Attack Flow

1. Attacker deposits collateral
2. Calls borrow() for AMP token
3. AMP's ERC777 hook triggers during transfer
4. In hook, attacker deposits more collateral + borrows again
5. Second borrow succeeds because first borrow's balance not updated yet
6. Repeat until drained

Fix

function borrow(uint amount) external nonReentrant {
    require(getAccountLiquidity(msg.sender) >= amount);
    borrowBalances[msg.sender] += amount;  // Update FIRST
    token.transfer(msg.sender, amount);
}

---

Fei Protocol / Ondo Finance (2022)

Loss: ~$80M Root Cause: Read-only reentrancy

Concept

// Protocol A's view function
function getExchangeRate() public view returns (uint) {
    return totalAssets / totalShares;  // Reads state
}

// Protocol B uses this
function deposit() external {
    uint rate = protocolA.getExchangeRate();  // Gets STALE rate
    uint shares = amount * rate;
    // ...
}

Attack Flow

1. Attacker calls withdraw() on Protocol A
2. During callback (before state update), call Protocol B
3. Protocol B queries Protocol A's exchange rate
4. Rate is stale (doesn't reflect pending withdrawal)
5. Attacker gets more shares than deserved

Fix

• Check invariants in view functions
• Use mutex that view functions also respect
• Snapshot state at start of transaction

---

Rari Fuse (2022)

Loss: ~$80M Root Cause: Cross-function reentrancy

Pattern

function exitMarket(address cToken) external {
    // Check no borrows
    require(borrowBalances[msg.sender][cToken] == 0);
    
    // Update membership
    markets[msg.sender][cToken] = false;
}

function borrow(address cToken, uint amount) external {
    require(markets[msg.sender][cToken] == true);  // Must be in market
    
    // Transfer - REENTRANCY POINT
    cToken.transfer(msg.sender, amount);
    
    borrowBalances[msg.sender][cToken] += amount;
}

Attack

1. Enter market, deposit collateral
2. Call borrow()
3. In callback, call exitMarket() - passes because borrow balance not yet updated
4. Now out of market but have borrowed funds
5. Collateral released, borrow never repaid

---

Detection Checklist

• [ ] Map all external calls in each function
• [ ] Check state updates happen BEFORE external calls
• [ ] Verify nonReentrant modifier on vulnerable functions
• [ ] Check for ERC777/ERC721 callback hooks
• [ ] Look for cross-function shared state
• [ ] Check view functions for read-only reentrancy
• [ ] Verify flash loan callbacks don't enable reentrancy

---

Patterns by Token Type

| Token Type | Reentrancy Vector | |------------|-------------------| | ETH | call{value:}() | | ERC777 | tokensToSend, tokensReceived hooks | | ERC721 | onERC721Received | | ERC1155 | onERC1155Received, batch operations | | Flash loans | Callback functions |

---

Resources

• DeFiHackLabs: submodules/DeFiHackLabs/test/Reentrancy/
• learn-evm-attacks: submodules/learn-evm-attacks/test/Reentrancy/
• SWC-107: https://swcregistry.io/docs/SWC-107

Detection Heuristics (kadenzipfel)

Preconditions

• Contract makes an external call (ETH transfer, token transfer, .call(), .send(), .transfer(), callback hook)
• State is modified after the external call, not before
• No reentrancy guard (nonReentrant modifier) on the function
• For cross-function: two or more functions share state, and at least one makes an external call before updating that shared state
• For cross-contract: Contract B reads Contract A's state, and A makes an external call before updating it
• For read-only: Contract A has a reentrancy guard but updates state after an external call; Contract B reads A's state without sharing the same lock

Vulnerable Pattern

// Single-function reentrancy
function withdraw() external {
    uint256 bal = balances[msg.sender];
    // External call BEFORE state update
    (bool success,) = msg.sender.call{value: bal}("");
    require(success);
    // State update AFTER external call — attacker reenters withdraw()
    // and balances[msg.sender] is still the original value
    balances[msg.sender] = 0;
}

// Hidden external calls that trigger callbacks:
// ERC721._safeMint() -> onERC721Received()
// ERC1155.safeTransferFrom() -> onERC1155Received()
// ERC777 token transfers -> tokensReceived() hook

Detection Heuristics

1. Identify all external calls: .call(), .send(), .transfer(), token transfers, _safeMint(), _safeTransfer(), ERC777/ERC1155 safe transfers
2. For each external call, check if any state variable is written AFTER the call in the same function
3. If state is written after an external call, check if a nonReentrant guard is present on the function — flag if absent
4. Check for cross-function reentrancy: does the function share state with other functions that could be called during the reentrant window?
5. Check for cross-contract reentrancy: does any other contract read this contract's state that is stale during the external call?
6. Check for hidden callbacks: _safeMint, _safeTransfer, ERC777 hooks, ERC1155 hooks — these are external calls even though they don't look like .call()

False Positives

• State is updated BEFORE the external call (checks-effects-interactions pattern correctly followed)
• nonReentrant modifier is applied to the function
• The external call target is a trusted, immutable contract (e.g., WETH) with no callback mechanism
• The function is view/pure and cannot modify state
• The only state read after reentry is already finalized (e.g., immutable variables)

Remediation

• Apply the checks-effects-interactions pattern: perform all state changes before any external call
• Add OpenZeppelin's ReentrancyGuard with nonReentrant modifier to all functions that make external calls
• For cross-contract reentrancy, use a shared reentrancy lock across contracts or ensure state is finalized before external calls

function withdraw() external nonReentrant {
    uint256 bal = balances[msg.sender];
    balances[msg.sender] = 0;  // State update BEFORE external call
    (bool success,) = msg.sender.call{value: bal}("");
    require(success);
}