c4-submissions commented 10 months ago

Lines of code

https://github.com/code-423n4/2023-10-badger/blob/main/packages/contracts/contracts/PriceFeed.sol#L561

Vulnerability details

Impact

A fixed timeout threshold might cause an incorrect staleness check leading to the wrong price being computed.

Proof of Concept

In PriceFeed.sol, the timeout threshold for eth-btc feed and steth-eth feed is set as a constant

    // Maximum time period allowed since Chainlink's latest round data timestamp, beyond which Chainlink is considered frozen.
    uint256 public constant TIMEOUT_ETH_BTC_FEED = 4800; // 1 hours & 20min: 60 * 80
    uint256 public constant TIMEOUT_STETH_ETH_FEED = 90000; // 25 hours: 60 * 60 * 25

If the last updated time is greater than the timeout timing, then the feed is considered frozen.

    function _chainlinkIsFrozen(ChainlinkResponse memory _response) internal view returns (bool) {
        return
            _responseTimeout(_response.timestampEthBtc, TIMEOUT_ETH_BTC_FEED) ||
            _responseTimeout(_response.timestampStEthEth, TIMEOUT_STETH_ETH_FEED);
    }

    function _responseTimeout(uint256 _timestamp, uint256 _timeout) internal view returns (bool) {
        return block.timestamp - _timestamp > _timeout;
    }

The TIMEOUT variables are hardcoded and is a constant value, which will be an issue because Chainlink's heartbeat value might be changed in the future. For example, Chainlink may decrease the heartbeat for steth-eth oracle to 1 hour instead of the current 24 hours. If that's the case, then a check of 24 hours is extremely stale.

https://docs.chain.link/data-feeds

Changes are possible. Chainlink has changed their deviation threshold for Steth-eth from 2% to 0.5% before.