Liquid Staking

Summary

This report highlights a front-running vulnerability in the staking pool contract, specifically in the depositQueuedTokens and performUpkeep functions. The vulnerability could allow a malicious user to manipulate transaction ordering, potentially resulting in a loss of funds for other users.

Vulnerability Details

The staking pool contract manages the deposit and withdrawal of tokens, as well as the upkeep of unused tokens. Two key functions—depositQueuedTokens and performUpkeep—involve the transfer of tokens and updating the staking pool strategies.

These operations are susceptible to front-running, where a malicious user can exploit the transaction ordering on the blockchain. Front-runners could monitor pending transactions, submit their own transaction with a higher gas fee, and get their transaction mined first. This manipulation of transaction order can lead to unfair profit or cause other users' transactions to fail or incur extra costs.

Affected functions:

1. depositQueuedTokens(uint256 _queueDepositMin, uint256 _queueDepositMax, bytes[] calldata _data): This function allows for the deposit of queued tokens into staking pool strategies. If a user submits a transaction to deposit tokens, a malicious actor can front-run by depositing a large amount, preventing the user's transaction from processing as intended.

2. performUpkeep(bytes calldata _performData): This function deposits unused tokens into the staking pool strategies and could be front-run by malicious actors trying to prioritize their own deposits.

PoC:
Scenario:
Alice and Bob both want to deposit tokens into the staking pool. Alice submits a transaction to deposit 100 tokens at T1. However, Bob, who is monitoring the mempool, notices Alice’s transaction and front-runs her by submitting a deposit for 10,000 tokens with a higher gas fee. Bob's transaction gets mined first, filling the available deposit room and leaving Alice's transaction to fail due to insufficient deposit room.

Steps for PoC:

1. Deploy the Contract: The contract is deployed on a local Hardhat environment.

2. Initialize Users: Alice and Bob both have tokens to deposit into the staking pool.

3. Simulate Deposits:

   • At T1, Alice submits a transaction to deposit 100 tokens into the staking pool.

   • Bob submits a transaction at T2 (just milliseconds later), front-running Alice by offering a higher gas fee and depositing 10,000 tokens.

4. Result: Bob’s transaction is processed first, and the available deposit room is filled by his 10,000 tokens. Alice's transaction fails due to insufficient room, despite submitting her transaction first.

Hardhat test case for front-running:

Impact

1. Users with smaller deposits, like Alice in the example, may see their transactions fail if they are front-run, leading to wasted gas fees and failed operations.

2. Malicious actors with large amounts of tokens can manipulate the order of deposits, gaining an unfair advantage over other users in terms of staking returns or access to limited liquidity.

Tools Used

Manual review.

Recommendations

1. Introduce randomness to the order in which transactions are processed, making it more difficult for malicious actors to predict and front-run specific transactions.

2. Implement a two-phase commit-reveal mechanism for deposits. Users first commit their intent to deposit, and after a delay, reveal the actual deposit transaction. This makes it harder for attackers to front-run transactions.

3. Use a fair ordering mechanism, such as a First-In-First-Out (FIFO) queue or even-time windows to process transactions, ensuring that deposit transactions are fairly handled.

4. Set a cap on the gas fee for specific functions to prevent malicious actors from using high gas fees to front-run.