Renzo - bill's results

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L315-L321 https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L564-L569 https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L605-L609 https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L355

Vulnerability details

Impact

When users apply for a withdrawal, they deposit ezETH into the WithdrawQueue. In RestakeManager.sol, the function renzoOracle.calculateMintAmount calculates how much new ezETH to mint, taking into account the ezETH in the WithdrawQueue, and calculateTVLs() also accounts for the collateral in the WithdrawQueue.

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

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

The issue here is that the exchange ratio between ezETH and collateral is fixed at the time of withdrawal application. Any rewards earned by the protocol after this application do not affect this ratio. However, including these deposited ezETH in the TVL calculation can dilute subsequent users' staking rewards and can be manipulated to influence the price of ezETH.

Based on this vulnerability, an further attack scenario can be constructed, assuming the protocol's TVL is initially 0:

1. An attacker deposits ETH and immediately applies for a withdrawal without claiming it.
2. A victim deposits ETH, earning staking rewards for the protocol.
3. The attacker deposits more ETH and immediately executes the claim from step (1).

Through this attack process, the attacker can realize an instant profit in step three, derived from the staking rewards earned by the victim.

Proof of Concept

https://gist.github.com/StillFantastic/26338c38774d9e1dfe87d2420737c010

Tools Used

Manual review

Recommended Mitigation Steps

In the calculateTVLs function of RestakeManager.sol, the calculation should exclude claimReserve from the WithdrawQueue, and the total supply of ezETH should also deduct the ezETH in the WithdrawQueue.

Assessed type

Context

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Withdraw/WithdrawQueue.sol#L156-L162

Vulnerability details

Impact

WithdrawQueue uses the getAvailableToWithdraw function to calculate the current amount available for withdrawal. Amounts that have been applied for withdrawal but not yet claimed are recorded in claimReserve and are deducted from the contract’s balance.

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Withdraw/WithdrawQueue.sol#L156-L162

However, for rebase tokens like stETH, which uses shares for the underlying accounting, it's possible for the balance of an address's stETH to decrease if there is a loss in the Lido protocol. In scenarios where most of the stETH in the WithdrawQueue has been applied for withdrawal, the calculation of balance minus claimReserve could be very close or equal to zero. If the stETH balance then decreases, this could cause the contract to experience an underflow error.

Since the protocol's minting and withdrawal functions both use the getAvailableToWithdraw function, if such a situation occurs, both minting and withdrawal functionalities will become unusable.

Proof of Concept

https://gist.github.com/StillFantastic/5ff507216f55427052b3755c3d217ea0

Tools Used

Manual review

Recommended Mitigation Steps

It is recommended to add an additional check in getAvailableToWithdraw to return zero directly when the balance is less than claimReserve.

Assessed type

DoS

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L542-L562 https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Delegation/OperatorDelegator.sol#L147-L148

Vulnerability details

Impact

In RestakeManager.sol, when users deposit LST collateral, the protocol first uses this collateral to fill any deficiencies in the WithdrawQueue. Only the remaining amount is then deposited into the OperatorDelegator contract.

When the deficit in the WithdrawQueue is greater than or equal to the amount deposited by the user, the subsequent amount to be deposited into OperatorDelegator is reduced to zero. However, the OperatorDelegator contract performs a check on the deposit amount, and if it is zero, an InvalidZeroInput error is thrown, causing the transaction to fail.

Proof of Concept

https://gist.github.com/StillFantastic/cad063751da00348ae192a60319b9865

Tools Used

Manual review

Recommended Mitigation Steps

It is recommended to check whether the amount is zero before executing the deposit function in OperatorDelegator.

Assessed type

DoS