howlbot-integration[bot] commented 6 months ago

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Bridge/L2/Oracle/RenzoOracleL2.sol#L13 https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Bridge/L2/Oracle/RenzoOracleL2.sol#L52

Vulnerability details

Impact

The stale period 86400 + 60 seconds used for the oracle price validation is too short for some tokens like ezETH for example on Arbitrum. This could lead to the protocol consuming stale prices on Arbitrum.

Proof of Concept

In both RenzoOracle and RenzoOracleL2, the hearbeat period MAX_TIME_WINDOW is set to 86400 + 60; // 24 hours + 60 seconds. In the functions RenzoOracleL2::getMintRate and RenzoOracle::lookupTokenValue, a validation checks sees if the price data fed by Chainlink's price feed aggregators is stale depending if the period of 24 hours + 60 seconds has passed. Example :

    function getMintRate() public view returns (uint256, uint256) {
        (, int256 price, , uint256 timestamp, ) = oracle.latestRoundData();
        if (timestamp < block.timestamp - MAX_TIME_WINDOW) revert OraclePriceExpired();

The problem is that depending on the token and the chain, the same period can be considered too small or too stale.

Let's consider the ezETH/ETH oracles on different chains:

On Ethereum, the oracle will update the price data every ~24 hours.
On Arbitrum, the oracle will update the price data every ~6 hours.
On Linea, the oracle will update the price data every 24 hours. ...

This means that on Arbitrum, 24 hours can be considered too large for the stale period which will cause the function RenzoOracleL2::getMintRate to return stale data.

Tools Used

Manual review

Recommended Mitigation Steps

It is recommanded to store a mapping that would record the hearbeat parameter for the stale period of each token and for every different chain.