c4-bot-5 commented 4 months ago

Lines of code

https://github.com/code-423n4/2024-04-panoptic/blob/main/contracts/PanopticPool.sol#L1086-L1092 https://github.com/code-423n4/2024-04-panoptic/blob/main/contracts/SemiFungiblePositionManager.sol#L1013-L1018

Vulnerability details

Impact

The PanopticPool.liquidate function is used to liquidate a distressed account by burning all the positions of a liquidatee. In the liquidate function the PanopticPool._burnAllOptionsFrom internal function is called. In the execution flow of the PanopticPool._burnAllOptionsFrom function the SemiFungiblePositionManager._createLegInAMM function is called to create a the respective position in the AMM for a specific leg in the tokenId.

In the SemiFungiblePositionManager._createLegInAMM function uses the following condition to check whether the respective position has enough liquidity in the UniswapV3Pool to be removed for a respective long position. In the event of a liquidation this check will be performed when closing a short position by creating a long position.

                 if (startingLiquidity < chunkLiquidity) {

The issue here is if a malicious user front-runs the liquidation transaction and create a considerably large long position (within the same tick range of tickLower - tickUpper in the UniswapV3 pool) making the startingLiquidity < chunkLiquidity then the subsequent liquidation transaction will revert since startingLiquidity < chunkLiquidity condition will result in true and the if statement will revert.

Hence the liquidations could revert as a result till more liquidity is added to that liquidity position in the respective UniswapV3Pool. If the liquidations can not be performed as a result of reverting due to above vulnerability, the entire panoptic protocol could become insolvent thus putting the user funds of the PLPs and the options creators in danger since they could lose the provided funds to the Panoptic protocol.

Proof of Concept

            (netExchanged, premiasByLeg) = _burnAllOptionsFrom(
                liquidatee,
                Constants.MIN_V3POOL_TICK,
                Constants.MAX_V3POOL_TICK,
                DONOT_COMMIT_LONG_SETTLED,
                positionIdList
            );

https://github.com/code-423n4/2024-04-panoptic/blob/main/contracts/PanopticPool.sol#L1086-L1092

                if (startingLiquidity < chunkLiquidity) {
                    // the amount we want to move (liquidityChunk.legLiquidity()) out of uniswap is greater than
                    // what the account that owns the liquidity in uniswap has (startingLiquidity)
                    // we must ensure that an account can only move its own liquidity out of uniswap
                    // so we revert in this case
                    revert Errors.NotEnoughLiquidity();

https://github.com/code-423n4/2024-04-panoptic/blob/main/contracts/SemiFungiblePositionManager.sol#L1013-L1018

Tools Used

Manual Review and VSCode

Recommended Mitigation Steps

The Panoptic Protocol uses the liquidation bots to identify liquidatable accounts. Hence if this liquidation bot can be developed to calculate the liquidity in the distressed short positions, then that value can be reduced from the available liquidity in the UniswapV3 pool when creating the long positions (where liquidity will be removed). As a result a malicious user (could be liquidatee himself) will not be able to front-run a liquidation transaction and remove liquidity from a position such that closing of the distressed position will revert due to not having enough liquidity in the position as explained above.

Assessed type

DoS

c4-judge commented 4 months ago

Picodes marked the issue as primary issue

dyedm1 commented 4 months ago

Liquidators will sometimes have to sell options as a last resort to complete a liquidation -- this was explained in the contest README: "It's expected that liquidators may have to sell options, perform force exercises, and deposit collateral to perform some liquidations. In some situations, the liquidation may not be profitable."