Manipulation via `slot0`

[howlbot-integration[bot]]

Lines of code

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

Vulnerability details

The use of slot0 is not always advised as slot0 is essentially the spot price of any given pool and can be easily manipulated using a flashloan to move the price to a new tick. In the Predy protocol, the attacker can leverage this and get a desired price return when getSqrtPrice during a trade. This can allow them to trade at an unfair advantage at the expense of the other users.

tradeResult.sqrtPrice = getSqrtPrice(pairStatus.sqrtAssetStatus.uniswapPool, pairStatus.isQuoteZero);

An attacker can also leverage this to cause excessive reallocations by moving the tick and then calling the reallocate function multiple times. This will move the tick range used by the specific pool and prevent the lenders from collecting fees while there is no trading at the current range.

(uint160 currentSqrtPrice, int24 currentTick,,,,,) = IUniswapV3Pool(_sqrtAssetStatus.uniswapPool).slot0();

Impact

Trades and reallocations can both be manipulated to hurt liquidity providers of the protocol.

Proof of Concept

1. Current tick is 0.
2. Pool's acceptable range is +/- 10.
3. Alice makes a large swap on the UniV3 pool that Predy references, moving the tick to -10,000.
4. Alice calls reallocate repeatedly until the tick is at -10,000.
5. Alice swaps back to bring the tick back to 0.

Tools Used

Manual analysis

Recommended Mitigation Steps

Where it is important that atomic manipulation should not be used, don't use slot0 as a reference point.

Assessed type

Oracle

[c4-judge]

alex-ppg marked the issue as not a duplicate

[c4-judge]

alex-ppg marked the issue as duplicate of #209

[c4-judge]

alex-ppg marked the issue as satisfactory