Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Description
Brief/Intro
protocol checks historical data to calculate Time-Weighted Average Price for a Chainlink feed from all the prices between the latest round and the latest round before the time interval. But checking the historical data is incorrect according to the chainlink docs which can damage some serious logic with in the protocol. Since liquidation amount, borrow amount is calculated from fetching price of asset(i.e processPriceFeed)
Vulnerability Details
unction getTwapPrice( AggregatorV3Interface chainlink,uint80 latestRoundId,uint256 latestPrice,uint256 twapTimeInterval ) internalviewreturns (uint256 price) {uint256 priceSum = latestPrice;uint256 priceCount =1;uint256 startTime = block.timestamp - twapTimeInterval;/// @dev Iterate over the previous rounds until reaching a round that was updated before the start timewhile (latestRoundId >0) {try chainlink.getRoundData(--latestRoundId) returns (uint80,int256 answer,uint256,uint256 updatedAt,uint80 ) {if (updatedAt < startTime) {break; } priceSum += answer.toUint256(); priceCount++; } catch {//@audit-issue roundId doesn't decrement one one break; } }return priceSum / priceCount; }
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
so it is not mendatory that there will be valid data for currentRoundID-1. if there is not data for currentRooundId-1 then it will just return the weighted average till that time.
weighted average was mean to be from currentTimestamp to currentTimestamp-twapTimeInterval but it will end of returning spot price which is too close to currentTimestamp failing all the logic of using TWAP price.
check this - https://docs.chain.link/data-feeds/historical-data#solidity
roundId is NOT incremental. Not all roundIds are valid. You must know a valid roundId before consuming historical data.
Impact Details
HubPool::updatePoolWithDeposit()
HubPool::preparePoolForBorrow()
Liquidation::calcLiquidationAmounts()
LoanManager::executeDepositFToken()
etc. All these crucial function fetch balance from Chainlink oracles and due to above issue instead of using TWAP till twapTimeInterval they will end up consuming more spot price breaking logic of TWAP.
Recommendations
As chainlink docs says.
Increase in roundId may not be monotonic so loop through the previous roundID and fetch the previoous roundId data
Proof of concept
Proof of Concept
Replace MockChainlinkAggregator::getRoundData() with the below getRoundData() function. It reverts with a RoundId doesn't exist error, which is the root cause of the issue. Since Chainlink doesn't provide data for every roundID, there will be roundIDs for which getRoundData() reverts
Paste the below test in ChainlinkNode.test.ts, run the test, and it can be seen that the test shows that TWAP is the same as the spot price due to an issue in ChainlinkNode::getTwapPrice(), which validates the issue that Chainlink getTwapPrice() is returning the spot price instead of the TWAP price.
Linking an issue where a similar implementation was used. The linked issue is also submitted by me. They accepted it as Medium severity since it was not used in critical functions.
But Here in Folks Finance it is used in calculation of liquidation amounts, borrow positions etc. makes it high severity
iterate (from roundId-1 to untill we get previous first data corressponding to roundID){
if(data present for roundID){
fetch the data and return
}else{
again iterate to get the data
}
}