The lending protocol allows anyone to call the updateState function, which updates the liquidity and usage indices by calculating interest based on small time intervals (e.g., 1 second). This functionality uses a Taylor series approximation for compound interest, which can lead to small discrepancies in the interest calculation when frequent state updates are triggered. Malicious actors could exploit this by frequently calling updateState, potentially gaining an unfair advantage in interest accrual over time, especially with large sums of money.
The vulnerability stems from the ability of any user to call updateState arbitrarily, which updates the reserve's state, including the liquidity index and usage index. The calculations for interest, particularly compound interest, are sensitive to the frequency and precision of updates. The current code uses a Taylor series approximation for compound interest, which can cause small discrepancies when dealing with very small time intervals (e.g., 1 second).
In particular:
For linear interest, the calculations are straightforward, but for compound interest, the Taylor series approximation introduces small errors.
Frequent updates over a large position (e.g., $100 million) can accumulate these small errors, resulting in significant financial advantages for malicious actors who spam the updateState function.
A malicious actor with a large position could repeatedly call the updateState function, compounding interest at a higher rate than intended, leading to unfair profits over time.
Protocol Instability: Frequent calls to update the state could cause excessive gas consumption, leading to higher operational costs and potential network congestion. This could also degrade the user experience for other participants.
Inaccurate Reserve State: If the reserve state is updated too frequently, it could cause the liquidity and usage indices to diverge from their intended values, impacting the overall protocol's economic balance.
A malicious actor deposits $100 million USDC into the protocol.
They repeatedly call the updateState function every second (or near-frequently).
Over time, this causes small but cumulative discrepancies in the compound interest calculation, resulting in the malicious actor accruing more interest than they should.
After several hours or days, the actor accumulates a substantial advantage due to the manipulation of interest calculations, potentially draining funds or destabilizing the protocol.
PoC Code:
Run Test:
Result:
Manual
Limit the Frequency of Updates:
Introduce a mechanism to limit how often updateState can be called, such as a cooldown period between updates or a maximum number of calls per block. This would prevent malicious actors from spamming the function.
Restrict Access to Authorized Entities:
Implement role-based access control (e.g., using OpenZeppelin's Ownable or AccessControl) to ensure that only authorized entities (such as protocol governance or liquidity pool managers) can call updateState.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.