Summary

Possible vulnerabilities in the getMaxDeposits() and deposit() functions facilitate a front-running-based DoS attack. By strategically manipulating the available deposit space, an attacker can prevent large depositors from successfully staking their tokens, leading to significant operational and reputational damage.

https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/linkStaking/base/VaultControllerStrategy.sol#L437C4-L445C6

https://github.com/Cyfrin/2024-09-stakelink/blob/f5824f9ad67058b24a2c08494e51ddd7efdbb90b/contracts/linkStaking/base/VaultControllerStrategy.sol#L573-L586

IMPACT

It calculates the maximum allowable deposits based on the current state, including total deposits, active stakes, and withdrawals. But does not account for pending transactions in the mempool that could alter the available deposit space. This omission allows an attacker to predict and manipulate the available deposit capacity by submitting transactions that adjust the state just before a large deposit is processed.

1. deposit(uint256 _amount, bytes calldata _data)

   function deposit(uint256 _amount, bytes calldata _data) external virtual onlyStakingPool {

   if (vaultDepositController == address(0)) revert VaultDepositControllerNotSet();

   ​

   (bool success, ) = vaultDepositController.delegatecall(

   abi.encodeWithSelector(VaultDepositController.deposit.selector, _amount, _data)

   );

   ​

   if (!success) revert DepositFailed();

   }

2. The deposit function delegates the deposit logic to the VaultDepositController. Then if the VaultDepositController.deposit method relies on getMaxDeposits() without additional safeguards, it inherits the vulnerability. An attacker can exploit this by front-running large deposit transactions, causing the getMaxDeposits() calculation to fail for legitimate large deposits.

3. VaultDepositController.deposit(uint256 _amount, bytes calldata _data)

   function getMaxDeposits() public view virtual override returns (uint256) {

   (, uint256 maxDeposits) = getVaultDepositLimits();

   return

   totalDeposits +

   (

   stakeController.isActive()

   ? MathUpgradeable.min(

   vaults.length * maxDeposits - totalPrincipalDeposits,

   ((stakeController.getMaxPoolSize() - stakeController.getTotalPrincipal()) *

   maxDepositSizeBP) / 10000

   )

   : 0

   );

   }

## Vulnerability Details

Illustration of how an attacker can exploit the vulnerabilities

1. • Deposit Limit: 250k tokens.

   • Active Stake: 110k tokens.

   • Withdrawals: 38k tokens.

   • Available for Deposit: 250k - 110k - 38k = 102k tokens.

2. Actors:

   • Alice: A whale intending to deposit 100k tokens.

   • Bob: A smaller depositor aiming to deposit 3k tokens.

   • Mallory: An attacker intending to disrupt Alice's deposit.

3. Attack Steps:

   1. Alice's Intent to Deposit:

      • Alice prepares a transaction to deposit 100k tokens.

      • This transaction enters the mempool, awaiting confirmation.

   2. Mallory Monitors the Mempool:

      • Using Mempool Monitoring tools, Mallory detects Alice's pending deposit transaction.

   3. Mallory Executes the Attack:

      • Mallory crafts a malicious deposit transaction to deposit 1,001 tokens.

      • This specific amount is calculated to reduce the available deposit space just enough to cause Alice's transaction to fail:

        • New Available Deposit Space: 102k - 1,001 = 100,999 tokens.

   4. Submission of Mallory's Transaction:

      • Mallory submits the 1,001-token deposit transaction with higher gas fees to prioritize its inclusion in the next block.

      • Due to higher gas fees, Mallory's transaction is processed before Alice's.

   5. Processing of Transactions:

      • Mallory's Transaction:

        • Successfully deposits 1,001 tokens.

        • Updates the contract's state, reducing the available deposit space to 100,999 tokens.

      • Alice's Transaction:

        • Attempts to deposit 100k tokens.

        • The contract calls getMaxDeposits() and calculates the available space as 100,999 tokens.

        • Since 100k ≤ 100,999, Alice's deposit should technically succeed. However, if the available space was marginally reduced further (e.g., if multiple small deposits were made), Alice’s transaction could revert.

      (Note: To ensure Alice's deposit fails, Mallory might need to deposit slightly more, e.g., 2,001 tokens, reducing available space to 100,999 - 1,001 = 99,998, making Alice’s 100k deposit exceed the limit.)

   6. Outcome:

      • Alice's Deposit:

        • Reverts due to insufficient available deposit space.

        • Alice experiences a Denial of Service, as her large deposit does not go through.

      • Mallory's Position:

        • Successfully disrupts Alice's deposit without direct financial loss, leveraging her position to cause operational disruption.

4. Extended Exploitation:

   • Upon observing the success of the initial attack, Mallory could automate this strategy:

     • Deploy a Front-Running Bot that constantly monitors the mempool for large deposit transactions.

     • Automatically submit strategically calculated small deposits to reduce available space below the large deposit thresholds.

     • Repeat this process, effectively DoSing any large depositor attempting to stake significant amounts.

Summary of Attack Flow

Mallory monitors the mempool for large deposit transactions.

Upon detecting a large deposit intent (e.g., Alice's 100k tokens), Mallory calculates the exact amount needed to reduce the available deposit space.

Mallory submits a small deposit transaction with higher gas fees to ensure it is mined first.

The large deposit transaction (Alice's) fails due to insufficient available deposit space, causing a DoS for the intended depositor.

The attacker can continuously apply this strategy against multiple large depositors, exacerbating the Denial of Service effect.

Implications

Legitimate large depositors are unable to stake their tokens, undermining trust in the staking platform.

## Recommendations

Set a threshold to prevent small deposits from blocking larger ones.