code-423n4 / 2024-05-predy-findings

10 stars 9 forks source link

UniV3 Oracle Manipulation on L2s #260

Closed howlbot-integration[bot] closed 3 months ago

howlbot-integration[bot] commented 4 months ago

Lines of code

https://github.com/code-423n4/2024-05-predy/blob/a9246db5f874a91fb71c296aac6a66902289306a/src/libraries/UniHelper.sol#L35

Vulnerability details

Impact

The cost of manipulating the TWAP in L2 network is too low so TWAP should not be used in L2

Proof of Concept

Predy uses TWAP prices in places such as when liquidating a user. According to the information provided by the Uniswap team, as documented in the Uniswap Oracle Integration on Layer 2 Rollups guide, primarily addresses the integration of Uniswap oracle on L2 Optimism. However, it is relevant to note that the same concerns apply to Arbitrum as well. Arbitrum's average block time is approximately 0.25 seconds, making it vulnerable to potential oracle price manipulation.

Oracles Integrations on Layer 2 Rollups

On Optimism, every transaction is confirmed as an individual block. The block.timestamp of these blocks, however, reflect the block.timestamp of the last L1 block ingested by the Sequencer. For this reason, Uniswap pools on Optimism are not suitable for providing oracle prices, as this high-latency block.timestamp update process makes the oracle much less costly to manipulate. In the future, it's possible that the Optimism block.timestamp will have much higher granularity (with a small trust assumption in the Sequencer), or that forced inclusion transactions will improve oracle security. For more information on these potential upcoming changes, please see the Optimistic Specs repo. For the time being, usage of the oracle feature on Optimism should be avoided.

In predy The Oracle period is even hardcoded to 30 mins which makes the manipulation much easy. And After getting the twap period it calculates the price of the already manipulated pool in here

/.......
....
...
        int56[] memory tickCumulatives = abi.decode(data, (int56[]));

        int24 tick = int24((tickCumulatives[1] - tickCumulatives[0]) / int56(int256(ago)));

        uint160 sqrtPriceX96 = TickMath.getSqrtRatioAtTick(tick);

        return (sqrtPriceX96, ago);

Tools Used

Uniswap

Recommended Mitigation Steps

Fetch the oracle source from chainlink in place of twap

Assessed type

Uniswap

syuhei176 commented 4 months ago

oracle manipulation is the out of scope

alex-ppg commented 3 months ago

The Warden outlines that the TWAP employed by Predy is less costly to influence due to the project's deployment on an L2, however, such an attack would still involve multi-block price adjustments that fall under the known risks of the protocol. As such, this submission is considered out-of-scope.

c4-judge commented 3 months ago

alex-ppg marked the issue as unsatisfactory: Out of scope