Cross-Function Reentrancy

This $18.8 million loss involved the AMP token and its unique pre-transfer hook mechanism. The attacker:

• Used a flash loan to supply AMP as collateral.
• Borrowed other assets.
• The AMP token's hook allowed a reentrant call to the lending pool's borrow function again before the initial borrow transaction finalized.
• This bypassed the protocol's collateral checks, allowing the attacker to borrow far more than their collateral should have permitted. It underscored that non-standard token implementations (ERC-777, ERC-1363) require special consideration in DeFi integrations.

Exploited a cross-protocol reentrancy vulnerability between Fei Protocol's PCV (Protocol Controlled Value) deposits and Rari Capital's Fuse pools. The attacker:

• Called a function that withdrew FEI from a Fuse pool to a Fei PCV contract.
• Reentered during the token transfer to call a function that minted new FEI, artificially inflating the pool's balance.
• This allowed the attacker to drain approximately $80 million. The root cause was a violation of the Checks-Effects-Interactions pattern across two tightly integrated but separately governed protocols.

The primary defense against all reentrancy, mandated after these exploits. Code must be structured in this strict order:

• Checks: Validate all conditions and inputs (e.g., balances, permissions).
• Effects: Update all internal state variables (e.g., deduct balances, increment counters).
• Interactions: Perform external calls to other contracts or EOAs last.
• This ensures the contract's state is in a consistent and finalized condition before any external call that could trigger a reentrant attack. Modern development frameworks often enforce this pattern.

A widely adopted technical mitigation, popularized by OpenZeppelin libraries. It is a mutex lock that prevents a function from being called recursively.

• When a function with the nonReentrant modifier is entered, a boolean flag is set to true.
• Any reentrant call to a protected function will fail because the flag is already set.
• The flag is reset to false only after the original function execution fully completes.
• While effective for single-contract reentrancy, it does not fully protect against cross-function or cross-protocol reentrancy, which require rigorous application of the Checks-Effects-Interactions pattern.

These historical cases led to fundamental shifts in smart contract security:

• Audit Focus: Reentrancy, especially cross-protocol, became a top priority for security auditors.
• Standardization Push: Increased caution around integrating tokens with callback hooks (ERC-777, ERC-1363).
• Protocol Design: Modern DeFi protocols now explicitly design for composition risks, implementing delayed effects or using pull-over-push payment patterns for critical operations.
• Developer Education: The Checks-Effects-Interactions pattern is now a foundational teaching point in smart contract development.

Cross-function reentrancy occurs when an external call allows an attacker's contract to call back into the vulnerable contract, but into a different function than the original one. This exploits shared state variables that the second function assumes are valid, but which have not yet been finalized by the first. Unlike single-function reentrancy, the attack vector is not direct recursion but lateral movement within the contract's interface.

• Example: A withdraw() function sends funds before updating a balance, allowing a reentrant call to transfer() which also reads the same, un-updated balance.

The primary defense is the Checks-Effects-Interactions (CEI) pattern. This strict ordering of operations prevents state inconsistencies before any external calls are made.

1. Checks: Validate all conditions and inputs (e.g., require(balance[msg.sender] >= amount)).
2. Effects: Update all internal state variables before any interaction (e.g., balance[msg.sender] -= amount).
3. Interactions: Perform external calls last (e.g., msg.sender.call{value: amount}("")).

By finalizing state changes first, any reentrant call into another function will read the correct, updated state.

A reentrancy guard is a function modifier that uses a boolean lock (nonReentrant) to prevent any reentrant calls for the duration of a function's execution. This is a robust, generalized solution.

• Implementation: A modifier sets locked = true on entry and locked = false on exit, reverting if a reentrant call is attempted.
• Scope: Modern guards (e.g., OpenZeppelin's ReentrancyGuard) are often applied to entire functions, protecting against both single-function and cross-function reentrancy.
• Consideration: Guards add gas cost and do not replace the need for correct internal logic and CEI where state dependencies are complex.

The pull-over-push pattern mitigates reentrancy by shifting the risk of external calls. Instead of a contract "pushing" funds to users (an active external call), users "pull" their owed funds from the contract in a separate transaction.

• Mechanism: Store a record of a user's entitlement (e.g., withdrawableBalance[user]). Let the user call a withdraw() function to claim it.
• Benefit: The vulnerable external call is initiated by the user, not the core contract logic, removing the reentrancy window from critical state-update functions.
• Use Case: Preferred for batch operations or payments to untrusted addresses.

Preventing cross-function reentrancy requires careful design to isolate state variables or ensure their updates are atomic across related functions. Functions that share critical state must be protected as a group.

• Risk: A transferFrom() function that shares a balances mapping with mint() is vulnerable if mint is called reentrantly before transferFrom updates the state.
• Mitigation: Apply a reentrancy guard to all functions that read/write the same sensitive state, or refactor to use the CEI pattern rigorously in each.
• Audit Focus: Mappings and global variables are common attack surfaces for this vulnerability.

The 2016 attack on The DAO is the canonical example of reentrancy, demonstrating both single and cross-function variants. The vulnerable splitDAO function performed an external call to send Ether before updating the attacker's internal token balance.

• Cross-Function Vector: The reentrant call was made to the withdrawRewardFor function, which relied on the same, not-yet-updated balance state.
• Impact: This allowed the attacker to repeatedly drain funds, leading to a loss of 3.6M ETH and the Ethereum network's contentious hard fork.
• Legacy: This event directly led to the standardization of the CEI pattern and reentrancy guards as fundamental security practices.

A fundamental secure development practice that dictates the order of operations within a function to mitigate reentrancy risk.

• Checks: Validate all conditions and inputs (e.g., balances, permissions).
• Effects: Perform all state updates before any external call (e.g., deducting balances, updating counters).
• Interactions: Make external calls to other contracts last. This pattern prevents an attacker's callback from interacting with an inconsistent intermediate state, which is the root cause of cross-function reentrancy.

The classic form of reentrancy attack, where a malicious contract re-enters the same function it is currently executing. This is typically prevented by a simple reentrancy guard. Cross-function reentrancy is a more subtle variant where the callback targets a different function in the same victim contract that shares state with the initially called function.

Data permanently stored in a smart contract. Cross-function reentrancy exploits the manipulation of shared state variables between multiple functions. For example, an attacker might call Function A, which makes an external call. The malicious callback then invokes Function B, which reads a state variable that Function A has not yet finalized updating (e.g., a user's balance). Understanding and managing state dependencies is key to prevention.

The most famous real-world example of a reentrancy attack, which led to the loss of 3.6 million ETH and the Ethereum hard fork. While not exclusively cross-function, it demonstrated the catastrophic impact of violating the Checks-Effects-Interactions pattern. The attacker's contract recursively called the vulnerable splitDAO function before the victim's internal balance was updated, allowing repeated withdrawals.