No minAnswer/maxAnswer Circuit Breaker Checks while Querying Prices in Oracle.sol

Summary

The kept.sol contract, while currently applying a safety check (this can be side stepped, check my other submission ) to ensure returned prices are greater than zero, which is commendable, as it effectively mitigates the risk of using negative prices, there should be an implementation to ensure the returned prices are not at the extreme boundaries (minAnswer and maxAnswer). Without such a mechanism, the contract could operate based on incorrect prices, which could lead to an over- or under-representation of the asset's value, potentially causing significant harm to the protocol.

Vulnerability Detail

Chainlink aggregators have a built in circuit breaker if the price of an asset goes outside of a predetermined price band. The result is that if an asset experiences a huge drop in value (i.e. LUNA crash) the price of the oracle will continue to return the minPrice instead of the actual price of the asset. This would allow user to continue borrowing with the asset but at the wrong price. This is exactly what happened to Venus on BSC when LUNA imploded.

In its current form, the _etherPrice() function within the Kept.sol contract retrieves the latest round data from Chainlink, if the asset's market price plummets below minAnswer or skyrockets above maxAnswer, the returned price will still be minAnswer or maxAnswer, respectively, rather than the actual market price. This could potentially lead to an exploitation scenario where the protocol interacts with the asset using incorrect price information.

Take a look at this

function _etherPrice() private view returns (UFixed18) {
        (, int256 answer, , ,) = ethTokenOracleFeed().latestRoundData(); //@audit chainlink related issues
        return UFixed18Lib.from(Fixed18Lib.ratio(answer, 1e8)); // chainlink eth-usd feed uses 8 decimals
    }

Illustration:

1): Present price of TokenA is $10 2): TokenA has a minimum price set at $1 on chainlink 3): The actual price of TokenA dips to $0.10 4): The aggregator continues to report $1 as the price.

Consequently, users can interact with protocol using TokenA as though it were still valued at $1, which is a tenfold overestimate of its real market value.

Impact

The potential for misuse arises when the actual price of an asset drastically changes but the oracle continues to operate using the minAnswer or maxAnswer as the asset's price. In the case of it going under the minAnswer malicious actors obviously have the upperhand and could give their potential going to zero worth tokens to protocol

Code Snippet

https://github.com/sherlock-audit/2023-07-perennial/blob/main/root/contracts/attribute/Kept.sol#L61-L64

Tool used

Manual Review

Recommendation

It should check the returned answer against the minPrice/maxPrice and revert if the answer is outside of the bounds:

if (answer >= maxPrice or answer <= minPrice) revert();

Duplicate of #151

sherlock-audit / 2023-07-perennial-judging

BugBusters - No minAnswer/maxAnswer Circuit Breaker Checks while Querying Prices in Oracle.sol #33