📘Understanding Read-Only Reentrancy

Book an audit with Zokyo

The realm of blockchain technology and smart contracts continuously evolves, offering numerous benefits but also presenting multifaceted security challenges. Among these, the traditional reentrancy attack has always taken center stage. However, a subtler variation of this attack, often overshadowed by its infamous counterpart, is the "read-only reentrancy" vulnerability. This article seeks to demystify this often-misunderstood concept, its implications, and how developers can fortify their contracts against it.

1. Historical Backdrop

Before diving deep, it's essential to understand the genesis of reentrancy attacks. The 2016 DAO hack, which led to the loss of $60 million worth of Ether, was a watershed moment in Ethereum's history, thrusting reentrancy attacks into the limelight. It was primarily a traditional reentrancy attack, but it set the stage for in-depth exploration of similar vulnerabilities, including read-only reentrancy.

2. What is Read-Only Reentrancy?

At its core, a reentrancy attack involves an external contract interrupting the execution of a calling contract, leading to unintended behavior. While the traditional reentrancy attack focuses on maliciously modifying state variables or draining funds, read-only reentrancy is subtler. This vulnerability stems from state reads after an external call, potentially allowing an attacker to manipulate return data and deceive the calling contract.

3. Implications of Read-Only Reentrancy

You might wonder, "How impactful can reading a variable be?" The subtlety lies not in the reading itself, but in the consequences of relying on potentially tainted data:

• Misleading Outcomes: Contracts might make crucial decisions based on the returned data, leading to unintended consequences.

• Gas Usage: A clever attacker might craft a read-only reentrancy to increase the gas consumption of a transaction intentionally, causing it to fail due to out-of-gas errors.

• Confusion Attacks: Even without any direct monetary benefit, attackers can exploit these vulnerabilities to create confusion or reduce trust in a smart contract's reliability.

4. Mitigation Strategies

The best strategies are proactive, understanding potential threats and nullifying them during the development phase:

• Check-Effects-Interactions: Always update state variables before making external calls. Though this won't eliminate read-only reentrancy directly, adhering to this pattern reduces the overall surface area for attacks.

• Reentrancy Guard: Utilize a reentrancy guard, which locks the contract against reentrant calls. This is a straightforward way to eliminate most reentrancy risks, but always ensure you don't introduce new vulnerabilities.

• Avoid State Reads After External Calls: If possible, avoid reading state variables after external calls. If you must, ensure that you validate or sanitize the read data.

// Using a reentrancy guard
bool private locked = false;

modifier noReentrancy() {
    require(!locked, "Reentrant call");
    locked = true;
    _;
    locked = false;
}

function sensitiveFunction() external noReentrancy {
    // Your code here
}