sherlock-admin2
commented
1 year ago 4 comment(s) were left on this issue during the judging contest.
panprog commented:
invalid, because no scenario with funds loss is presented (how it can be reentered and used)
tsvetanovv commented:
You haven't described at all how the attack could happen
MohammedRizwan commented:
invalid issue
chrisling commented:
the issue simply describes a type of vulnerability without explanation or proof of concept to show how the vulnerability applies to the protocol.
Milad-Sha
high
readonly reentrancy on getrate()
Summary
Rewards.getRate() call on a pool is not protected from the read-only reentrancy.
Vulnerability Detail
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.
Read-only reentrancy occurs where a view function is called and reentered into during the execution of another function that modifies the state of that contract. This could potentially lead to stale data since what is read in memory during function invocation and what is recorded in storage has yet to be finalized and may be out of sync.
Impact
As a result, functions or contracts that rely on the returned value can be exploited which may lead to undesirable/malicious behaviour (rate manipulation).
Code Snippet
https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/Ledger.sol?plain=1#L162
Tool used
Manual Review
Recommendation
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.
The Balancer team recommends utilizing their official library to safeguard queries such as Rewards.getRate.