Open howlbot-integration[bot] opened 3 months ago
alcueca marked the issue as not a duplicate
alcueca changed the severity to 3 (High Risk)
alcueca marked the issue as duplicate of #326
alcueca changed the severity to 2 (Med Risk)
alcueca marked the issue as satisfactory
alcueca changed the severity to 3 (High Risk)
@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".
alcueca marked the issue as not a duplicate
alcueca changed the severity to QA (Quality Assurance)
alcueca marked the issue as grade-b
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 inRestakeManager#calculateTVLs
, one can monitorDepositQueue#sweepERC20
transactions,deposit
before them, initiate the withdrawal right after (at a higher ezETH exchange rate), and claim it aftercoolDownPeriod
, stealing rewards from honest depositors who have been holding ezETH for a significantly longer duration.Proof of Concept
sweepERC20
transaction in the mempool;sweepERC20
transaction is mined;coolDownPeriod
.Recommended Mitigation Steps
Include DepositQueue's balance in calculateTVL's, minus the fee that would be deduced during
sweepERC20
.Assessed type
Other