Steadefi

Summary

Steadefi checks for historical data to make sure that last price update are within maximum delya allowed and in the range of maximum % deviation allowed.

But checking the historical data is incorrect according to the chainlink docs which can damage some serious logic with in the protcol

Vulnerability Details

Vault calls ChainlinkARBOracle.consult(token) to get the fair price from chainlink oracle

https://github.com/Cyfrin/2023-10-SteadeFi/blob/main/contracts/oracles/ChainlinkARBOracle.sol#L62

which calls an interval function _getPrevChainlinkResponse() and try to fetch previous roundId price and other details

https://github.com/Cyfrin/2023-10-SteadeFi/blob/main/contracts/oracles/ChainlinkARBOracle.sol#L210

But this is incorrect way of fetching historical data.
chainlink docs say: `Oracles provide periodic data updates to the aggregators. Data feeds are updated in rounds. Rounds are identified by their roundId, which increases with each new round. This increase may not be monotonic. Knowing the roundId of a previous round allows contracts to consume historical data.

The examples in this document name the aggregator roundId as aggregatorRoundId to differentiate it from the proxy roundId.` check here

so it is not mendatory that there will be valid data for currentRoundID-1.
if there is not data for currentRooundId-1 then _badPriceDeviation(currChainlinkResponse,PrevResponse) check here will return true. Hence vault won't able to get the price of token at some specific times

Impact

1. In worse case keeper won't able to get the price of token so rebalancing , debt repay won't be possible leading to liquidation breaking the main important factor of protocol

2. Almost 70% of vault action is dependent on price of a token and not getting price will make them inactive affecting net APR

Tools Used

Manual Review

Recommendations

As chainlink docs says. Increase in roundId may not be monotonic so loop through the previous roundID and fetch the previoous roundId data

pseudo code