RestakeManager susceptible to an inflation attack

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Oracle/RenzoOracle.sol#L123-L149

Vulnerability details

Impact

First depositor can inflate the exchange rate of ezETH token such that any user who deposits afterwards receives less ezETH tokens for their deposits than they should. More info here, check example 2.

Proof of Concept

RestakeManager accepts ETH and ERC20 both as a collateral for minting ezETH token. Both could be used to perform this attack, however for simplicity, I'm going to show it for ETH deposits.

Let's have a look at the formula that is used to calculate the ezETHToMint,
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/Oracle/RenzoOracle.sol#L123-L149

        uint256 inflationPercentaage = (SCALE_FACTOR * _newValueAdded) /
            (_currentValueInProtocol + _newValueAdded);

        // Calculate the new supply
        uint256 newEzETHSupply = (_existingEzETHSupply * SCALE_FACTOR) /
            (SCALE_FACTOR - inflationPercentaage);

        // Subtract the old supply from the new supply to get the amount to mint
        uint256 mintAmount = newEzETHSupply - _existingEzETHSupply;

The mintAmount is determined by subtracting _existingEzETHSupply from the newEzETHSupply, since those value already calculated above, we can simplified it futher for better view.

	// looks familiar
        uint256 mintAmount = (_newValueAdded * _existingEzETHSupply) / _currentValueInProtocol; 

the _existingEzETHSupply and _currentValueInProtocol(e.g. tvl) intiallialy are 0,

To perform an attack;

• An attacker deposit 1 wei of ETH via depositETH(), since _existingEzETHSupply=0, the ezETHToMint is same as 1 wei
  https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/Oracle/RenzoOracle.sol#L130-L132

        if (_currentValueInProtocol == 0 || _existingEzETHSupply == 0) {
            return _newValueAdded; // value is priced in base units, so divide by scale factor
        }

• another depositETH() txn sent by a legimate user with 2 ETH of assets. Attacker saw it and try to frontrun it by a depositQueue.forwardFullWithdrawalETH(1 ether) call,

Note here, we cannot directly sent 1 ETH to depositQueue, since receive() will triggered and charge fee on the attacker sent amount.

The forwardFullWithdrawalETH() function here doing same as direct deposit will, also this call fill the withdraw buffer if required(means sending required fraction to withdrawQueue), but that won't be a problem, we'll see ahead.

• For victim during it deposits,

_newValueAdded = 2 ETH,
_existingEzETHSupply = 1 WEI,
_currentValueInProtocol = totalTVL

totalTVL is retrieved from calculateTVLs() function during the deposits, it can seen below that the totalTVL includes eth balance from depositQueue and withdrawQueue(which possibly filled during forwardFullWithdrawalETH call above) contract as well,
https://github.com/code-423n4/2024-04-renzo/blob/519e518f2d8dec9acf6482b84a181e403070d22d/contracts/RestakeManager.sol#L351-L356

        // Get the value of native ETH held in the deposit queue and add it to the total TVL
        totalTVL += address(depositQueue).balance;

        // Add native ETH help in withdraw Queue and totalWithdrawalQueueValue to totalTVL
        totalTVL += (address(withdrawQueue).balance + totalWithdrawalQueueValue);

So the totalTVL = 1 wei + 1 ETH from attacker

Due to rounding, the victim gets (2 ether * 1) / (1 ether + 1) == 1 shares which is same amount as the attacker. Attacker manage to steal (3 ether / 2) - 1 ether == 0.5 ether worth of extra shares from the victim.

        uint256 mintAmount = (_newValueAdded * _existingEzETHSupply) / _currentValueInProtocol; 

Tools Used

Manual review

Recommended Mitigation Steps

There are few mitigation strategies shared here, which could be implemented by Renzo.

Assessed type

ERC4626

[c4-judge]

alcueca marked the issue as unsatisfactory:
Invalid