Platform: Code4rena
Start Date: 30/04/2024
Pot Size: $112,500 USDC
Total HM: 22
Participants: 122
Period: 8 days
Judge: alcueca
Total Solo HM: 1
Id: 372
League: ETH
Rank: 71/122
Findings: 2
Award: $1.89
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: guhu95
Also found by: 0rpse, 0x007, 0x73696d616f, 0xCiphky, 0xabhay, Audinarey, Bauchibred, Fassi_Security, GalloDaSballo, GoatedAudits, KupiaSec, LessDupes, MSaptarshi, OMEN, Ocean_Sky, RamenPeople, SBSecurity, Tendency, WildSniper, aslanbek, bill, blutorque, crypticdefense, cu5t0mpeo, d3e4, gjaldon, grearlake, gumgumzum, honey-k12, ilchovski, jokr, josephdara, kennedy1030, p0wd3r, peanuts, stonejiajia, t0x1c, tapir, underdog, zzykxx
0.4071 USDC - $0.41
If the protocol receives any ETH, from Eigen Layer maybe as reward it is sent for fullWithdrawl via the DepositQueue contract after filling the withdraw buffer.
The withdrawQueue contract get filled by 3 ways -> New Deposits Daily Rewards Coming in the Protocol. Manual withdrawal from EigenLayer. Permissioned call from OperatorDelegator.
So for rewards coming in to the protcol users can claim those by calling the withdraw -> claim
An attacker can take advantage of this to steal a part of the rewards:
Mint a sensible amount of LRTTokens by depositing an accepted asset
Call WithdawlQueue.withdraw, after which the value of the LRTTokens just minted will immediately increase.
then claim those by claim
Here it only checks the cooldown period with the time when withdraw req was initiated for any type of withdrawl, which makes the possibility for sandwiching the rewards.
However the amount required to deposit for minting ezETH must be very high to disrupt the price ,since there is a presence of deposit buffer which might make it more costly
Manual Review
Making the distribution of rewards in a delayed manner
Error
#0 - c4-judge
2024-05-17T12:56:18Z
alcueca changed the severity to 3 (High Risk)
#1 - c4-judge
2024-05-17T12:56:37Z
alcueca marked the issue as duplicate of #326
#2 - c4-judge
2024-05-17T12:56:42Z
alcueca marked the issue as satisfactory
🌟 Selected for report: t0x1c
Also found by: 0xCiphky, 0xDemon, Bauchibred, DanielArmstrong, FastChecker, MSaptarshi, Maroutis, NentoR, Ocean_Sky, PNS, Rhaydden, SBSecurity, Shaheen, Tigerfrake, ZanyBonzy, atoko, btk, carlitox477, crypticdefense, honey-k12, hunter_w3b, ilchovski, jokr, ladboy233, rbserver, twcctop, umarkhatab_465
1.479 USDC - $1.48
The deposit function of the DepositQueue contract, enables users to deposit any erc20 assets that is supported into the protocol, getting ezETH tokens in return. The function doesn't have any type of slippage control; this is relevant in the context of the deposit function, since the amount of tokens received by the user is determined by an internal calculation, meaning that the amount received in return may vary indefinitely while the request is waiting to be executed.
The protocol uses chainlink price feeds to fetch the price for collateral amount so, users will have no defense against price manipulations attacks, if they where to be found after the protocol's deployment. https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L507 As can be observed by looking at its parameters and implementation, the deposit function of the DepositQueue contract, doesn't have any type of slippage protection: https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L491
Manual Review
USe a minAmountOut for a user expected deposit amountout
Other
#0 - c4-judge
2024-05-17T13:28:46Z
alcueca marked the issue as satisfactory