DepositQueue#sweepERC20 can be sandwiched

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L274

Vulnerability details

Impact

DepositQueue is expected to receive rewards in any of the collateral tokens. They are expected to be forwarded to OperatorDelegators via sweepERC20.

As the collateral balances of DepositQueue are not included in RestakeManager#calculateTVLs, one can monitor DepositQueue#sweepERC20 transactions, deposit before them, initiate the withdrawal right after (at a higher ezETH exchange rate), and claim it after coolDownPeriod, stealing rewards from honest depositors who have been holding ezETH for a significantly longer duration.

Proof of Concept

1. Alice sees a sweepERC20 transaction in the mempool;
2. Alice deposits ETH and mints ezETH;
3. sweepERC20 transaction is mined;
4. Alice starts a withdrawal of her ezETH at a higher price, and claims it after coolDownPeriod.

Recommended Mitigation Steps

Include DepositQueue's balance in calculateTVL's, minus the fee that would be deduced during sweepERC20.

Assessed type

Other

[c4-judge]

alcueca marked the issue as not a duplicate

[c4-judge]

alcueca changed the severity to 3 (High Risk)

[c4-judge]

alcueca marked the issue as duplicate of #326

[c4-judge]

alcueca changed the severity to 2 (Med Risk)

[c4-judge]

alcueca marked the issue as satisfactory

[c4-judge]

alcueca changed the severity to 3 (High Risk)

[aslanbekaibimov]

@alcueca

I believe this should be a duplicate of #383 as long as #383 is a separate issue from #326.

The root cause is "DepositQueue ERC20 balances are not accounted in TVL", and the attack path is "sandwiching sweepERC20".

[c4-judge]

alcueca marked the issue as not a duplicate

[c4-judge]

alcueca changed the severity to QA (Quality Assurance)

[c4-judge]

alcueca marked the issue as grade-b