Open c4-submissions opened 10 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as duplicate of #32
raymondfam marked the issue as not a duplicate
raymondfam marked the issue as duplicate of #194
raymondfam marked the issue as duplicate of #723
fatherGoose1 changed the severity to QA (Quality Assurance)
Lines of code
https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTOracle.sol#L52
Vulnerability details
Impact
The getRSETHPrice() function calculates the RSETH/ETH exchange rate based on the total value of assets in the LRT deposit pool, derived from individual asset prices fetched by getAssetPrice(), which in turn relies on Chainlink.
The function is potentially vulnerable to price manipulation if the oracle feeds can be tampered with, or if the pool balances can be artificially inflated, such as through a flash loan attack.
This price outrages provide a substantial attack surface for the protocol therefore it's worth adding some complexity to the current implementation.
Proof of Concept
The oracle vulnerability can be exploited if an attacker finds a way to manipulate the data feed of the oracle service. For instance, by exploiting a vulnerability in the chainlink data feed.
An attacker could also take a substantial loan of a supported asset, deposits it into the LRT deposit pool, calls getRSETHPrice() to get an inflated price, and then uses this inflated price for profit in other transactions within the same block before repaying the flash loan.
Tools Used
Manual Review
Recommended Mitigation Steps
Consider querying both the Chainlink oracle and Uniswap pool (TWAP implementation ) for latest prices, ensuring that these two values are within some upper/lower bounds of each other.
Slabbed under Medium risk as the function of the protocol or its availability could be impacted, or leak value with a hypothetical attack path with stated assumptions.
Assessed type
Oracle