Functions with callback, a big contribution to reentrancy attacks

Functions with callbacks have played a significant role in many reentrancy attacks, a common vulnerability in smart contracts. In this article, we will discuss the topic and explore how callbacks can contribute to reentrancy attacks, how these attacks work, and the measures to mitigate them.

When it comes to reentrancy, functions with callbacks seem like an easy target. They transfer control back to the external contract, creating an opening. But what do you think makes them so dangerous? Is it just that state updates happen after the callback, or do you think it’s more about how easily developers overlook the potential for malicious behaviour from these external contracts?

I think what makes callbacks particularly dangerous in smart contracts is that they hand over control to an external entity?—?without any guarantee about how that entity will behave. It’s like opening a door and expecting the guest not to mess with your house while you’re still rearranging things.

What is a Callback?

In programming, a callback is a function that is passed as an argument to another function, which can invoke the callback later when a certain event or condition occurs. In smart contracts, callbacks are often used to handle various operations, such as transferring funds, interacting with other contracts, or executing external logic.

Understanding Reentrancy Attacks

A reentrancy attack occurs when an external contract (or attacker) repeatedly calls back into the vulnerable contract before the initial execution is completed. This can happen when:

• A contract sends funds to another contract (often in the form of Ether or tokens).
• Before the internal state is updated (e.g., updating balances or bookkeeping), the receiving contract calls back into the original contract (using the callback mechanism) and re-executes part of the logic.
• This leads to an inconsistent state, allowing the attacker to exploit the contract and drain funds or cause other unintended behaviours.

Example of Reentrancy Vulnerability

Consider a simple smart contract that allows users to withdraw funds from their balance:

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    
    // Send Ether to the caller (this is where the callback happens)
    msg.sender.call{value: _amount}("");
    
    // Update the user's balance after the funds are sent
    balances[msg.sender] -= _amount;
}        

In this contract, an attacker can exploit the reentrancy vulnerability because the internal state (balances) is updated after the Ether transfer is made. If the msg.sender is a malicious contract, it can recursively call withdraw before its balance is updated, draining the contract's funds.

Reasons why I think callbacks are so risky in the context of reentrancy

1. Unpredictability of External Contracts

When a contract makes an external call (e.g., msg.sender.call{value: amount}("")), it assumes the external contract will behave as expected. But you can’t control the logic of external contracts. If the external contract is malicious or poorly designed, it might recursively call back into the original contract and exploit unfinished state transitions.

2. State Inconsistency

In smart contracts, the order of operations is key. If you allow a callback to execute before fully updating your contract’s internal state (like balances or flags), the external contract can take advantage of this partial state and make multiple calls before the system “catches up.” This makes it easy for attackers to perform operations like draining funds.

What makes it even trickier is that this inconsistency is subtle?—?everything looks fine if you only focus on the logic of the contract in isolation, which is how most people think. Developers may forget that handing off control during a callback means their contract is now vulnerable while in this partially updated state.

3. Complexity in Tracing the Execution Flow

Callbacks introduce asynchronous behavior, which can make it hard to track what’s happening. When an external contract can call back in the middle of an operation, it becomes like juggling multiple balls at once. If you don’t have the execution flow mapped out perfectly, it’s easy to miss vulnerabilities.

For example, in Solidity, developers might think the flow of logic is simple?—?withdraw() sends Ether and then updates the balance. But when you add a callback, the flow is interrupted, and the external contract might take actions the developer didn’t anticipate, like calling back into the vulnerable function before the balance is updated.

4. Lack of Visibility and Gas Mechanisms

Gas limits don’t always protect you. Even though you might think restricting gas (e.g., using?.call{gas: 2300}) will prevent complex reentrancy attacks, attackers can still find ways to re-enter through cheaper operations. It’s hard to predict exactly how much gas a reentrant call might need to cause damage, so you can’t rely solely on gas limitations as a defense.

5. False Sense of Security from Fallbacks

Many developers, especially in earlier stages, relied on Solidity’s send() and transfer() functions because they only forward 2300 gas units. The idea was that this wasn’t enough for a reentrant call to do anything significant. But attackers evolved. They realized they could get around these limitations by using fallback functions or delegatecall, which opened the door to executing more complex logic within that minimal gas limit.

That’s why the OpenZeppelin community and others now prefer using more concrete measures like reentrancy guards and checks-effects-interactions patterns.

6. Deceptive Simplicity

Callbacks make contract logic appear simple on the surface, but in reality, the contract is interacting with an entire ecosystem. This disconnect between apparent simplicity and actual complexity is dangerous. Developers often don’t see the attack surface that callbacks open up because it’s easy to overlook how an external contract might behave maliciously.

What do you think? Do you see callbacks as an inherently risky pattern, or do you think there are scenarios where they’re not as dangerous?

There are scenarios where callbacks aren’t inherently dangerous, especially if the smart contract is designed with care. While callbacks can create vulnerabilities, they aren’t always dangerous by themselves?—?it’s more about how they’re used and managed.

Scenarios where callbacks might not be as?risky:

1. When the External Contract’s Behavior is Fully?Trusted

If you’re interacting with a trusted contract, like one that has been thoroughly audited and has a strong track record of security, the risk of a reentrancy attack is reduced. For instance, interacting with well-known protocols like Uniswap or Aave may carry lower risks because these contracts are battle-tested and extensively used. But even in those cases, you’d still want to handle state updates properly.

In these cases, callbacks aren’t dangerous because the external contract isn’t likely to act maliciously. However, this assumes the trustworthiness of the other contract, which isn’t a luxury you always have.

2. When Using Low-Level Functions with?Care

Solidity’s send() or transfer() functions are often safer for transferring Ether because they impose a 2300 gas limit, which makes it difficult for an external contract to execute complex operations during a callback. This was considered a best practice for preventing reentrancy in the past. However, they’ve fallen out of favor for large-scale contracts due to their gas limitations.

In specific contexts where you’re confident that the callback will only perform basic operations (e.g., receiving Ether and nothing more), callbacks may not pose significant danger.

3. When the Contract State is Properly Updated Before the?Callback

If a smart contract follows the checks-effects-interactions pattern, it can minimize the risks associated with callbacks. The key here is that the contract’s internal state is updated before the external call is made.

For example:

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    
    //Update the user's balance first
    balances[msg.sender] -= _amount;

    //Then interact with the external contract
    (bool success) = msg.sender.call{value: _amount}("");
    require(success, "Transfer failed.");
}        

In this case, even if a callback occurs, the internal state has already been updated, so reentrant calls won’t cause any damage.

4. Callback for Non-Critical Actions

Sometimes, callbacks are used for non-critical operations that don’t affect sensitive contract logic, like emitting an event or logging data. For instance, if a contract triggers a callback that doesn’t involve fund transfers or state changes, the potential for reentrancy attacks is much lower.

For example, a callback could be used to notify an external system that a certain action has been completed:

function performAction() public {
    // Perform action
    someInternalFunction();

    // Notify an external contract (no funds or state manipulation)
    ExternalContract(msg.sender).notifyActionCompleted();
}        

n this case, the external contract can call back into the original contract, but it doesn’t pose a threat because no sensitive operations (like fund transfers) are being performed after the callback.

5. When Using Reentrancy Guards

If you use a reentrancy guard like OpenZeppelin’s ReentrancyGuard, callbacks are much less dangerous because the contract explicitly prevents reentrant calls. Here, the guard acts as a fail-safe mechanism that ensures reentrancy can’t happen, even if the external contract attempts it.

For example:

function withdraw(uint _amount) public nonReentrant {
    require(balances[msg.sender] >= _amount);
    balances[msg.sender] -= _amount;
    (bool success,) = msg.sender.call{value: _amount}("");
    require(success, "Transfer failed.");
}        

The nonReentrant modifier ensures that even if the callback function tries to reenter, it won’t be able to execute the withdraw logic again.

6. In Controlled Environments (e.g., Single-Call Functions)

If you can ensure that the contract only allows one logical call per action, callbacks become less dangerous. For example, using a lifecycle model where each function is triggered in stages?—?such as initializing, processing, and finalizing?—?limits the opportunity for reentrancy. For instance, a function that only allows a user to withdraw funds once per transaction (and doesn’t allow multiple recursive withdrawals) is less likely to be vulnerable, even if a callback occurs.

So, while callbacks can be risky, they aren’t dangerous in every situation. It all depends on context and how carefully the contract is designed. If the contract manages its internal state carefully (like using reentrancy guards or following proper patterns), the risks associated with callbacks can be mitigated or even eliminated.

I hope we’ve learnt a thing or two today. I hope we can discuss on more aspects of smart contract security soon.

Thank you for taking the time to go through this with me. You can check my other articles to know more about smart contracts, and solidity.

See you soon…