Front-running Risk Leading to Failed Withdrawals Due to Insufficient Collateral

[c4-bot-10]

Lines of code

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

Vulnerability details

Impact

Users can exploit this by monitoring the mempool and front-running large withdrawals, causing others to face failed transactions.

This creates a race condition where stakers might rush to withdraw their tokens, potentially leading to failed transactions and user frustration.

Proof of Concept

 function removeAsset(AssetStatus storage tokenState, uint256 _supplyTokenAmount, uint256 _amount)
        internal
        returns (uint256 finalBurnAmount, uint256 finalWithdrawAmount)
    {
        if (_amount == 0) {
            return (0, 0);
        }

        require(_supplyTokenAmount > 0, "S3");

        uint256 burnAmount = FixedPointMathLib.mulDivDown(_amount, Constants.ONE, tokenState.assetScaler);

        if (_supplyTokenAmount < burnAmount) {
            finalBurnAmount = _supplyTokenAmount;
        } else {
            finalBurnAmount = burnAmount;
        }

        finalWithdrawAmount = FixedPointMathLib.mulDivDown(finalBurnAmount, tokenState.assetScaler, Constants.ONE);

        require(getAvailableCollateralValue(tokenState) >= finalWithdrawAmount, "S0");

        tokenState.totalCompoundDeposited -= finalBurnAmount;
    }

POC

Initial State:

• Available Collateral Value: 1000 tokens.
• Staker A's desired withdrawal: 600 tokens.
• Staker B's desired withdrawal: 600 tokens.

Staker A's Withdrawal:

Staker A Initiates Withdrawal:

• Staker A calls the withdraw function, which in turn calls removeAsset.
• The function calculates burnAmount and finalWithdrawAmount for Staker A's 600 token withdrawal.

Collateral Check:

The function checks if the available collateral value is sufficient:

require(getAvailableCollateralValue(tokenState) >= finalWithdrawAmount, "S0");

• At this point, getAvailableCollateralValue(tokenState) returns 1000.
• The check 1000 >= 600 passes, so the withdrawal should proceed.

Front-running by Staker B:

Staker B Observes and Acts:

• Staker B monitors the mempool and sees Staker A's pending transaction.
• Staker B quickly submits a withdrawal transaction with a higher gas fee to ensure it is processed first.

Staker B's Withdrawal Process:

• Staker B's transaction to withdraw 600 tokens is processed before Staker A's transaction.
• The function calculates burnAmount and finalWithdrawAmount for Staker B's 600 token withdrawal.
• The available collateral value is checked and is initially 1000 tokens.
• The check 1000 >= 600 passes, and Staker B's withdrawal is processed.
• The available collateral value is now reduced to 400 tokens (1000 - 600).

Staker A's Withdrawal Fails:

Staker A's Transaction is Processed:

• After Staker B's withdrawal, Staker A's transaction is processed.
• The function recalculates burnAmount and finalWithdrawAmount for Staker A's 600 token withdrawal.

Collateral Check Fails:

• At this point, getAvailableCollateralValue(tokenState) returns 400 tokens.
• The check 400 >= 600 fails, causing Staker A's transaction to revert with the error "S0".

Tools Used

Manual Audit

Recommended Mitigation Steps

Process withdrawals in the order they are received.

Assessed type

MEV

[sathishpic22]

Hi @alex-ppg

This is well demonstrated with example . Also kind of issues accepted in many contests before. As per my scenario the frontrunning possible.

Please check this thank you

[alex-ppg]

Hey @sathishpic22, thanks for contributing to the PJQA process! This represents a validation repository finding and as such was not evaluated by me directly.

Withdrawals are processed in the order they are received, and it is impossible to avoid the described behavior which is usually known as a "bank run".