search

code-423n4 / 2023-11-kelp-findings

13 stars 11 forks source link

LRTOracle.sol - potential problems when integrating with Chainlink oracles #127

Closed c4-submissions closed 11 months ago

c4-submissions commented 11 months ago

Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/c5fdc2e62c5e1d78769f44d6e34a6fb9e40c00f0/src/interfaces/IPriceFetcher.sol#L1-L10 https://github.com/code-423n4/2023-11-kelp/blob/c5fdc2e62c5e1d78769f44d6e34a6fb9e40c00f0/src/LRTOracle.sol#L1-L110

Vulnerability details

Impact

The IPriceFether.sol interface and the LRTOracle.sol will be, as described by the sponsors, provider agnostic, meaning it should be able to be integrated with any oracle service to provide up-to-date prices. But also, as mentioned by the sponsors, initially Chainlink's pricing oracles will be used, which sometimes can come with unexpected behaviors, depending on token pairs.

Proof of Concept

The problem arises from the oracles stETH/ETH, cbETH/ETH and rETH/ETH, that would be the ones in use, since these are the main LSTs that will be compatible with the protocol. The minting mechanism of rsETH is highly dependent on the answers from these oracles and having them provide data every 24 hours opens the possibility of stale data, impacting how much rsETH a user could mint

Tools Used

Manual Review

Recommended Mitigation Steps

In case of Chainlink implementation, instead of directly referencing LST/ETH oracles, do LST/USD -> USD/ETH, since they are much more up to date.

Assessed type

Oracle

c4-pre-sort commented 11 months ago

raymondfam marked the issue as sufficient quality report

c4-pre-sort commented 11 months ago

raymondfam marked the issue as duplicate of #32

c4-pre-sort commented 11 months ago

raymondfam marked the issue as not a duplicate

c4-pre-sort commented 11 months ago

raymondfam marked the issue as duplicate of #843

c4-judge commented 10 months ago

fatherGoose1 marked the issue as unsatisfactory: Invalid