Renzo - 0xabhay's results

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/RestakeManager.sol#L491 https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Withdraw/WithdrawQueue.sol#L206

Vulnerability details

Impact

Following the launch of LRT, which will enable the deposit of native ETH and wrapped staking tokens like stETH or wBETH, Renzo users will face additional economic risks that could result in capital loss. In the event of an anticipated price decline, such as due to a slashing event in an external liquid staking provider, external users can deposit their funds into Renzo prior to the price drop. They will receive LRT equivalent to the value before the price decline, as priceFeed updates the price only after the event occurs. Subsequently, they can withdraw their funds once the price has dropped, thereby sharing their loss with Renzo users.

Proof of Concept

Users depositing their funds into Renzo are encouraged by the rewards of staking and re-staking through EigenLayer, but they also bear the risk of penalties and slashing of their deposited funds. However, in case of ezETh, the 3rd party users who are not associated in any way with Renzo ecosystem can take advantage of such LRT and make Rio users bear their losses.

Keeping in mind these things:

Assets like stETH and wBETH typically appreciate over time. While occasional price drops may occur, they are often temporary in nature. 

Factors contributing to such declines include slashing events, reduced demand, or a lack of trust in a particular asset. Notably, big withdrawals can be anticipated and slashing occurs gradually, allowing for a period of foresight into the asset's devaluation.

Liquid staking providers such as LIDO mitigate the risk of "withdrawal before slashing" by implementing extended withdrawal processes, ensuring that users who request withdrawals are susceptible to potential slashing.

Within the Renzo ecosystem, users can deposit asset1 to acquire LRT and subsequently request the withdrawal of asset2.

Consider the following scenario (values used for ease of calculation and to illustrate the attack, real values will be presented later in this description):

Renzo issues LRT (ezETH) that supports two assets (stETH, cbETh and native ETH).

Attacker holds 100 stETH (1 stETH = 2 ETH, so worth 200 ETH).
Attacker anticipates a price drop for stETH due to external events.

Attacker deposits 100 stETH into the protocol, receiving 200 ezETH (as 1 stETH = 2 ezETH).

TVL in the protocol increases from 200 ETH to 400 ETH (200 ETH + 200 ETH worth of stETH).

stETH price drops by 50% (now 1 stETH = 1 ETH).
TVL in the protocol decreases from 400 ETH to 300 ETH (200 ETH + 100 ETH worth of stETH).

Attacker burns 150 ezETH to withdraw their 100 stETH (now worth 100 ETH).

Attacker burns another 50 ezETH to withdraw 50 ETH.
Attacker ends up with 100 stETH (worth 100 ETH) and 50 ETH.
Attacker uses the 50 ETH to buy more stETH from another source, now holding 150 stETH.

When stETH price recovers to 1 stETH = 2 ETH, the attacker has 150 stETH worth 300 ETH, while the protocol and its users bear the loss of 50 ETH.

However, the price drop is not expected to reach 50%. The actual figures could be as high as 10%.

Looking specifically at stETH as an example of an asset considered for addition, we can observe the following: stETH down by 7%

Tools Used

Manual review

Recommended Mitigation Steps

1. Holding periods or cooldowns to delay withdrawals after deposits.

2. users could be allowed to withdraw only the type of assets they deposit

Assessed type

Error

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Withdraw/WithdrawQueue.sol#L206 https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Withdraw/WithdrawQueue.sol#L279

Vulnerability details

Impact

Stakers can exploit this timing gap to withdraw their staked tokens without incurring the losses that would normally result from penalties or slashing events.

Proof of Concept

A validator experiences penalties or is slashed, reducing their balance.

Before the TVL is updated via EigenPod::verifyBalanceUpdates() or EigenPod::verifyAndProcessWithdrawals(), a staker requests a withdraw all their LRTTokens using withdraw.

The staker then triggers the update of the TVL by calling one of the aforementioned functions. When withdraw is executed, the withdrawal is processed without accounting for the recent penalties or slashing, as the TVL drop is instantaneous upon the update.

for example:

Initial state: 2 validators 32 ETH each 10 users with equal LRT, 6.4 each.

1. Validator 1 is slashed for 16 ETH
2. User 1 front-runs verifyBalanceUpdates() with a call to tWithdrawal() and has sharesOwed = 6.4 since TVL is still 64 ETH.
3. verifyBalanceUpdates() is now called to update EigenLayer balance.
4. User 2 calls withdraw() and has sharesOwed = 4.8 since TVL has decreased to 48.

User 1 has stolen 1.4 ETH from the rest.

Tools Used

Manual Review

Recommended Mitigation Steps

Locking Period: Implement a locking period after a slashing event is detected, during which no withdrawals can be processed. This allows the system to update the TVL accordingly.

Assessed type

Context

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/RestakeManager.sol#L491 https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/RestakeManager.sol#L507 https://github.com/code-423n4/2024-04-renzo/blob/1c7cc4e632564349b204b4b5e5f494c9b0bc631d/contracts/Oracle/RenzoOracle.sol#L71

Vulnerability details

Impact

The depegging of stETH from ETH creates a discrepancy between the actual value of stETH and its expected parity with ETH. If an attacker front-runs the oracle update, they can mint ezETH at a stale price, obtaining an unfair advantage and potential profit. This action undermines the protocol's integrity and can lead to diminished user confidence and financial imbalances.

Proof of Concept

Market Change: stETH depegs. stETh down by 6% in terms of eth and the chailink deviation for stEth/ETH is 0.5% which will trigger the price feed tom update but attacker frontrun the oracle and mint the at stale price for profit , reducing its value compared to ETH.

Oracle Update: Chainlink's deviation threshold for stETH/ETH is 0.5%, triggering an impending price feed update.

Front-Running: The attacker observes the depegging event and anticipates the oracle update.

Minting at Stale Price: The attacker deposits stETH into the RestakeManager::deposit before the price feed updates.

Exploiting the Delay: The RestakeManager mints ezETH based on the outdated, more favorable price.

Oracle Update: The oracle adjusts the stETH/ETH price to reflect the current market value.

Profit Taking: The attacker sells the newly minted ezETH at the updated price, realizing a profit from the price difference.

Similar Issue.

Tools Used

Manual Review

Recommended Mitigation Steps

Implement a time-weighted average price (TWAP) oracle to mitigate front-running.

Slippage Checks: Add slippage checks to compare the expected mint amount with a threshold.

Assessed type

Oracle