Reentrancy attacks in Blockchain / Solidity - Deep Dive

Overview - Reentrancy attacks

What is it?

A reentrancy attack happens when a program, like a smart contract on a blockchain, calls another contract that then calls back into the original contract before the first call finishes. This can cause the original contract to behave in unexpected ways, often allowing attackers to steal money or break the rules. It is a common security problem in blockchain programming, especially in Ethereum smart contracts. Understanding it helps protect digital assets and maintain trust in decentralized systems.

Why it matters

Without protection against reentrancy attacks, attackers can repeatedly withdraw funds or manipulate contract states, causing huge financial losses and breaking trust in blockchain applications. This problem has led to some of the biggest hacks in blockchain history. Preventing these attacks keeps users' money safe and ensures smart contracts work as intended, which is crucial for the growing blockchain ecosystem.

Where it fits

Before learning about reentrancy attacks, you should understand how smart contracts work, especially function calls and state changes. After this, you can learn about other blockchain security issues like integer overflow, front-running, and secure contract design patterns.

Mental Model

Core Idea

A reentrancy attack exploits a contract calling back into itself before finishing its first task, allowing repeated actions that break expected rules.

Think of it like...

Imagine a bank teller who starts giving you money but before finishing, you slip back in line and ask for more money again and again before the teller closes your account balance. This lets you take more money than you should.

┌─────────────────────────────┐
│ Original Contract Function   │
│ 1. Check balance             │
│ 2. Send money                │
│ 3. Update balance            │
└─────────────┬───────────────┘
              │ Calls
              ▼
┌─────────────────────────────┐
│ Attacker Contract            │
│ 1. Receive money             │
│ 2. Call Original Contract    │
│    again before step 3       │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Smart Contract Calls

Concept: Smart contracts can call other contracts and wait for them to finish before continuing.

In blockchain, a smart contract is a program that runs on the network. When one contract calls another, it pauses its own work until the called contract finishes. This is like making a phone call and waiting for the other person to answer before continuing.

Result

You see that contract calls are synchronous and can trigger other contracts.

Understanding that contracts call each other and wait is key to seeing how reentrancy can happen.

2

Foundation

State Changes and Order of Operations

Concept: Contracts change their stored data (state) step by step during function execution.

When a contract runs a function, it might check some data, send money, then update its records. The order matters because if something interrupts before updating, the data might be wrong.

Result

You realize that changing state after sending money can be risky.

Knowing that state updates happen after external calls helps spot where attacks can sneak in.

3

Intermediate

How Reentrancy Exploits Callbacks

🤔Before reading on: do you think a contract can be called again before it finishes its first call? Commit to yes or no.

Concept: An attacker can make a contract call back into itself before the first call finishes, repeating actions unexpectedly.

If a contract sends money to another contract, that contract can run code that calls back into the original contract before it updates its balance. This lets the attacker withdraw money multiple times before the balance changes.

Result

You see how repeated calls can drain funds.

Understanding that callbacks can happen mid-function reveals the core of reentrancy attacks.

4

Intermediate

Common Vulnerable Pattern Example

🤔Before reading on: do you think updating balance before or after sending money is safer? Commit to your answer.

Concept: Contracts that send money before updating balances are vulnerable to reentrancy.

Example in Solidity: function withdraw(uint amount) public { require(balances[msg.sender] >= amount); (bool success, ) = msg.sender.call{value: amount}(""); require(success); balances[msg.sender] -= amount; } Here, money is sent before balance is updated, allowing reentrancy.

Result

This code allows attackers to call withdraw repeatedly before balance changes.

Knowing the order of operations prevents the most common reentrancy bug.

5

Intermediate

Reentrancy Guard Pattern

🤔Before reading on: do you think a simple lock can stop reentrancy? Commit to yes or no.

Concept: Using a lock variable to prevent reentrant calls stops the attack.

A reentrancy guard uses a boolean flag: bool locked = false; modifier noReentrancy() { require(!locked, "No reentrancy"); locked = true; _; locked = false; } function withdraw(uint amount) public noReentrancy { require(balances[msg.sender] >= amount); balances[msg.sender] -= amount; (bool success, ) = msg.sender.call{value: amount}(""); require(success); } This stops the contract from being called again during execution.

Result

Reentrancy attacks fail because the lock blocks repeated calls.

Understanding how a simple lock prevents reentrancy is a powerful defense technique.

6

Advanced

Checks-Effects-Interactions Pattern

🤔Before reading on: do you think changing state before external calls is safer? Commit to yes or no.

Concept: A best practice is to check conditions, update state, then interact with other contracts.

This pattern means: 1. Check all requirements. 2. Update your contract's state. 3. Call external contracts or send money. By updating state first, even if reentrancy happens, the contract's data is safe.

Result

Contracts following this pattern avoid reentrancy bugs.

Knowing this pattern helps write secure contracts by design.

7

Expert

Advanced Reentrancy Variants and Detection

🤔Before reading on: do you think reentrancy only happens with direct calls? Commit to yes or no.

Concept: Reentrancy can happen in complex ways, including indirect calls and fallback functions, making detection tricky.

Attackers can use fallback functions or nested calls to trigger reentrancy in unexpected ways. Static analysis tools and runtime monitoring help detect these subtle cases. Also, some attacks combine reentrancy with other bugs for bigger impact.

Result

You understand that reentrancy is not always obvious and requires careful analysis.

Knowing the complexity of reentrancy attacks prepares you for real-world security challenges.

Under the Hood

When a smart contract calls another, the Ethereum Virtual Machine (EVM) executes the called contract's code immediately and synchronously. If the called contract calls back into the original contract before the first call finishes, the original contract's state may not yet reflect changes expected after the first call. This allows the attacker to exploit inconsistent state and repeat actions like withdrawing funds multiple times.

Why designed this way?

The EVM was designed for synchronous calls to keep execution simple and atomic. However, this design allows reentrancy because the contract's state changes are not automatically isolated between calls. Alternatives like asynchronous calls or automatic state snapshots were not chosen due to complexity and gas cost concerns.

┌───────────────────────────────┐
│ Original Contract Function     │
│ ┌───────────────────────────┐ │
│ │ Step 1: Check balance      │ │
│ │ Step 2: Call external      │ │
│ │ contract (send money)      │ │
│ └─────────────┬─────────────┘ │
│               │ Calls          │
│               ▼               │
│ ┌───────────────────────────┐ │
│ │ Attacker Contract          │ │
│ │ Calls back Original Contract│
│ └─────────────┬─────────────┘ │
│               │ Reentrant call│
│               ▼               │
│ ┌───────────────────────────┐ │
│ │ Original Contract Function │ │
│ │ (reentered before Step 3)  │ │
│ └───────────────────────────┘ │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think reentrancy attacks only happen if the attacker is the contract owner? Commit to yes or no.

Common Belief: Only the contract owner or trusted parties can cause reentrancy attacks.

Reality: Any external user or contract can trigger reentrancy if the contract is vulnerable, regardless of ownership.

Why it matters: Assuming only owners can attack leads to ignoring vulnerabilities and losing funds to outsiders.

Quick: Do you think using 'transfer' or 'send' always prevents reentrancy? Commit to yes or no.

Common Belief: Using Solidity's 'transfer' or 'send' functions prevents reentrancy attacks automatically.

Reality: 'transfer' and 'send' limit gas but do not fully prevent reentrancy; attackers can still exploit fallback functions with enough gas or use other techniques.

Why it matters: Relying solely on these functions gives a false sense of security and can lead to attacks.

Quick: Do you think reentrancy attacks only affect withdrawing money? Commit to yes or no.

Common Belief: Reentrancy attacks only happen when contracts send money out.

Reality: Reentrancy can affect any function that changes state and calls external contracts, not just withdrawals.

Why it matters: Ignoring non-financial reentrancy risks can cause subtle bugs and security holes.

Quick: Do you think reentrancy is impossible if you use modern Solidity versions? Commit to yes or no.

Common Belief: Newer Solidity versions automatically prevent reentrancy attacks.

Reality: Solidity provides tools but does not automatically prevent reentrancy; developers must still write secure code.

Why it matters: Overtrusting language features can lead to careless coding and vulnerabilities.

Expert Zone

1

Reentrancy can occur through fallback or receive functions that execute on plain Ether transfers, not just explicit function calls.

2

Gas stipend limits in 'transfer' and 'send' can be bypassed by attackers using smart contract wallets with fallback functions consuming less gas.

3

Combining reentrancy with other vulnerabilities like unprotected access control or integer overflow can multiply attack impact.

When NOT to use

Reentrancy guards and patterns are not needed in contracts that do not call external contracts or send Ether. In such cases, simpler state management or immutable contracts are better. Also, for very complex interactions, consider using pull payments or escrow patterns instead of direct transfers.

Production Patterns

In production, developers use the Checks-Effects-Interactions pattern combined with reentrancy guards. They also use static analysis tools and formal verification to detect vulnerabilities. Some systems separate funds management into dedicated contracts to minimize attack surface.

Connections

Race Conditions in Operating Systems

Both involve unexpected interleaving of operations causing inconsistent state.

Understanding race conditions helps grasp how reentrancy exploits timing and order of execution to cause bugs.

Database Transactions and Isolation Levels

Reentrancy is like a transaction that reads stale data before commit, breaking atomicity.

Knowing database isolation concepts clarifies why updating state before external calls prevents reentrancy.

Security Locks in Physical Systems

Reentrancy guards act like locks preventing multiple entries into a critical section.

Seeing reentrancy guards as locks helps understand their role in controlling access and preventing repeated actions.

Common Pitfalls

#1 Sending money before updating balance allows repeated withdrawals.

Wrong approach:

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

Correct approach:

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

Root cause:

The contract sends money before updating state, allowing reentrant calls to exploit unchanged balances.

#2 Not using a reentrancy guard when calling external contracts.

Wrong approach:

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

Correct approach:

bool locked = false;
modifier noReentrancy() {
require(!locked, "No reentrancy");
locked = true;
_;
locked = false;
}

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

Root cause:

Without a lock, the contract can be reentered during the external call, enabling attacks.

#3 Assuming 'transfer' prevents all reentrancy.

Wrong approach:

function withdraw(uint amount) public {
require(balances[msg.sender] >= amount);
balances[msg.sender] -= amount;
payable(msg.sender).transfer(amount);
}

Correct approach:

Use Checks-Effects-Interactions pattern and reentrancy guards even when using 'transfer'.

Root cause:

Relying on gas limits of 'transfer' ignores advanced attack methods that bypass these limits.

Key Takeaways

Reentrancy attacks exploit the ability of a contract to be called again before finishing its first call, causing repeated actions that break contract logic.

The order of operations matters: always update contract state before calling external contracts or sending money to prevent attacks.

Using reentrancy guards and following the Checks-Effects-Interactions pattern are essential defenses against these attacks.

Reentrancy is a subtle and complex vulnerability that requires careful coding, testing, and analysis to fully prevent.

Understanding reentrancy connects to broader concepts like race conditions and transaction isolation, deepening your security mindset.