What Is Read-Only Reentrancy?

Smart contracts can contain a variety of different vulnerabilities, and some are more well-known than others. One of the most famous smart contract vulnerabilities is re-entrancy (or reentrancy), which was the cause of the infamous DAO hack and many hacks since.

In recent months, many DeFi protocols have suffered attacks exploiting read-only reentrancy vulnerabilities. This article provides more detail about how read-only reentrancy attacks work and how they differ from traditional reentrancy vulnerabilities.

What is a Reentrancy Vulnerability?

Reentrancy vulnerabilities exist if a smart contract programmer uses a seemingly-logic design pattern for certain actions. This includes:

• Check if an action is valid

• Perform the action

• Update records to reflect that the action has been performed
  

This design pattern is problematic because of how Solidity handles transfers of value to a smart contract. When a token like ETH is sent to a smart contract, it triggers the smart contract’s fallback function, which allows that contract to run some code. This could allow the contract to update its own internal records or perform some action in response to receiving that value.

The existence of fallback functions is problematic because the recipient smart contract could reenter the vulnerable function. For example, consider the case where a smart contract implements a withdrawal function that checks if a withdrawal request is valid, performs the withdrawal, and then updates the user’s balance.

If a smart contract calls this withdrawal function with a valid request, it will pass the initial check and the withdrawal will be sent to the smart contract. This will trigger the smart contract’s fallback function, which could call the same withdrawal function again before the user’s balance is updated. If the first request is valid and the withdrawal function’s records have not changed, then the second request will be valid as well. More value will be sent to the attacking smart contract, triggering its fallback function, and allowing the process to repeat again.

In Solidity, the main defense against an infinite withdrawal through a reentrancy vulnerability is the gas limit. Since a transaction can only use so much gas, the number of reentrancies that the attacker can perform into the withdrawal function is limited. The attacker needs to leave enough gas behind that the smart contract can finish its operations and the transaction completes successfully.

What is a Read-Only Reentrancy Attack?

Traditional reentrancy attacks are a well-known threat, and many smart contracts have defenses against them. However, these contracts often focus their defenses on functions that perform state updates, like the withdrawal function that changes the user’s balance.

Read-only reentrancy attacks target view functions that contain reentrancy vulnerabilities. These functions don’t change the state of the function but may have other important roles, such as reporting the perceived values of tokens.

By exploiting the reentrancy vulnerability, the attacker can manipulate these values or cause the contract to report outdated values. This enables them to exploit smart contracts that rely on these values.

3 Ways to Protect Against Reentrancy Attacks

Reentrancy vulnerabilities are a well-known threat to smart contract security, and read-only reentrancy is just a different variation of this vulnerability. 

Here are 3 ways you can protect against reentrancy attacks:

1. Design Patterns: Use the check-effects-interactions design pattern, updating internal state before performing an action that can call an external contract.

2. Price Oracles: Read-only reentrancy is often exploited to change the perceived value of tokens. Using trusted external price oracles like Chainlink can help to protect against this.

3. Reentrancy Guards: Reentrancy guards can help to protect against reentrancy attacks and should be extended to view functions as well as those that update the program state.

All of these mechanisms can be used to help protect against reentrancy vulnerabilities, but the most effective defense is a comprehensive smart contract audit. Auditing all smart contract code before release enables reentrancy and other vulnerabilities to be found and fixed before they can be exploited. To learn more about Halborn’s smart contract assessment services, get in touch.