Closed c4-bot-5 closed 3 months ago
raymondfam marked the issue as insufficient quality report
raymondfam marked the issue as duplicate of #4
See #4.
hansfriese marked the issue as unsatisfactory: Out of scope
hansfriese marked the issue as not a duplicate
hansfriese removed the grade
hansfriese marked the issue as satisfactory
hansfriese marked the issue as duplicate of #252
hansfriese marked the issue as duplicate of #164
Check #164 for details.
hansfriese marked the issue as partial-50
Lines of code
https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/libraries/LibOracle.sol#L19-L67
Vulnerability details
Proof of Concept
Take a look at https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/libraries/LibOracle.sol#L19-L67
This function is used to get the price from the oracle, it now includes a try/catch logic in order to ensure a more robust integration, issue here is that there are two deviaitional implementation of the price returned depending on Chainlink's
latestRoundData()
availaability, if the call in the try block fails for whatever reason the execution goes to the catch block, now in the catch block, issue however is not pertaining to this but more fo how the checks applied tooracleCircuitBreaker
&baseOracleCircuitBreaker
are different, here are snippets from both implementation:https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/libraries/LibOracle.sol#L117-L129
And https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/libraries/LibOracle.sol#L69-L77
Evidently there is a deviation in the checks applied, the
baseOracleCircuitBreaker()
has a correct stale check integrated with it, i..eblock.timestamp > 2 hours + timeStamp
which ensures that the price being ingested is not older than the accepted 2 hours value, however this is not present in theoracleCircuitBreaker
check and as such would mean that protocol would probably ingest heavily outdated data, wheneveroracle != baseOracle
Impact
Inaccurate prices would be used , completely breaking the logic of all the pricing functionalities attached to the protocol
Recommended Mitigation Steps
Consider having the correct checks in both helper fucntions.
Assessed type
Oracle