0x52 - TWAP manipulation of held Bunni tokens can be used to DOS entire RBS system

[sherlock-admin2]

0x52

high

TWAP manipulation of held Bunni tokens can be used to DOS entire RBS system

Summary

When valuing Bunni tokens, the function will revert if the price is currently outside an acceptable variation. If the valuation of even one of these tokens reverts it will DOS the entire RBS system. A malicious user could manipulate the TWAP of the lowest liquidity token to cause a revert and DOS the RBS at keys times to exploit pricing differences.

Vulnerability Detail

BunniSupply.sol#L458-L473

uint256 reservesTokenRatio = BunniHelper.getReservesRatio(key_, lens_);
uint256 twapTokenRatio = UniswapV3OracleHelper.getTWAPRatio(
    address(key_.pool),
    twapObservationWindow_
);

// Revert if the relative deviation is greater than the maximum
if (
    // Not necessary to use `isDeviatingWithBpsCheck()` as the checked is already performed in `addBunniToken`
    Deviation.isDeviating(
        reservesTokenRatio,
        twapTokenRatio,
        twapMaxDeviationBps_,
        TWAP_MAX_DEVIATION_BASE
    )
) {

_validateReserves will revert if the price of the token is too far away from the TWAP. This is generally a good thing but it becomes weak point to the RBS system. RBS depends on this function via the following (long) chain of calls:

Operator#operate => Appraiser#getMetric(liquid_backing_per_backed_OHM) => Appraiser#_liquidBackingPerBackedOhm => Appraiser#_liquidBacking => Appraiser#_backing => OlympusSupply#getReservesByCategory("protocol-owned-liquidity") => BunniSupply#getProtocolOwnedLiquidityReserves => BunniSupply#_validateReserves

Operator#operate is ESSENTIAL for the RBS system to function/update correctly. By purposely timing the DOS a malicious party could prevent the RBS system from adjusting properly in volatile conditions. This can lead to abuse of RBS pricing that is outdated.

To accomplish this, a malicious party could target a low liquidity pool and beginning trading it a highly depressed values to artificially lower the TWAP. With the TWAP maliciously lowered, all calls to operate the RBS will revert.

Impact

RBS can be DOS'd at opportune times for attackers

Code Snippet

BunniSupply.sol#L452-L480

Tool used

Manual Review

Recommendation

Cache previous reserve rates for Bunni tokens. If the token value using the cached value is larger than a set threshold and the token is deviating from it's TWAP then the RBS system should gracefully shut down or fallback to a simpler methodology.

[0xJem]

A few reasons to dispute this:

• The revert due to a failed deviation check can be avoided by being more lenient with the TWAP max deviation bps value, which is configured on a per-asset basis. Therefore, this isn't a fundamental issue with the system/contract, but a mis-configuration.
• The deviation check relates to the TWAP of a Uniswap V3 pool, which can be very expensive to manipulate over multiple blocks
• "If the token value using the cached value is larger than a set threshold and the token is deviating from it's TWAP then the RBS system should gracefully shut down or fallback to a simpler methodology." - if there's a revert, RBS won't run (== shut down). There are also monitors for late heartbeats (through which all of this is triggered), which would aid in quick diagnosis of the cause. Failing fast in this way (though it's avoidable) seems better than obfuscating the issue and complicating the code further.

It can be avoided through configuration:

• reasonable TWAP deviation check
• all assets have multiple price feeds (ideally one that is invulnerable to manipulation, e.g. UniV3 pool)
• all assets use the MA internally

[IAm0x52]

Escalate

This should be a medium issue. No matter how "reasonable" the TWAP deviation check. Through multi-block manipulation an attacker can quickly, safely and wildly manipulate the TWAP of low liquidity pools. Due to this external requirement I believe medium is more appropriate than high.

[sherlock-admin2]

Escalate

This should be a medium issue. No matter how "reasonable" the TWAP deviation check. Through multi-block manipulation an attacker can quickly, safely and wildly manipulate the TWAP of low liquidity pools. Due to this external requirement I believe medium is more appropriate than high.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[nevillehuang]

@IAm0x52 I don't see how your submission prove the feasibility of manipulating TWAP. I believe such an attack vector is complex enough to warrant a required PoC based on this sherlock rule

In case of non-obvious issues with complex vulnerabilities/attack paths, Watson must submit a valid POC for the issue to be considered valid and rewarded.

Additionally, Olympus has many factors in place to mitigate this.

[IAm0x52]

Many articles detailing multi-block TWAP manipulations, like this one by chainsecurity does a very good job analyzing it: https://chainsecurity.com/oracle-manipulation-after-merge/

[Czar102]

I believe this reliance on imperfect oracles is by design and I believe there are ways to mitigate this in case an oracle reading causes a revert. @IAm0x52

[Czar102]

Result: Invalid Unique

[sherlock-admin]

Escalations have been resolved successfully!

Escalation status:

• IAm0x52: rejected