`LRTDepositPool` is vunerable to inflation attack.

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/ee1154fcb6f6619cdc9aeda27503d9a2cbf6d8eb/src/LRTDepositPool.sol#L95-L110 https://github.com/code-423n4/2023-11-kelp/blob/ee1154fcb6f6619cdc9aeda27503d9a2cbf6d8eb/src/LRTDepositPool.sol#L119

Vulnerability details

Impact

LRTDepositPool is vunerable to inflation attack. Malicious can send asset token directly to dos the contract.

Proof of Concept

This issue is very similar to the well-known ERC4626 inflation attack.

Take a look at function getRSETHPrice,the price calculation formula is: totalETHInPool / rsEthSupply. Attack steps:

1. Malicious user deposit a very tiny value for example 1 wei stEth after protocol initialized. The totalETHInPool = 1wei * 1e18 ,and rsEthSupply will be 1wei, so getRSETHPrice will return to 1e18, it's a normal return value.
2. Malicious user direct transfer 1 stEth or other asset to this LRTDepositPool, now totalETHInPool increase to 1 ether,but rsEthSupply still is 1wei, so the getRSETHPrice will return 1e18 * 1e18 =1e36, notice the annotation of this function rsETHPrice exchange rate of RSETH, for the exchange rate, 1e36 is an extremely large value.
3. Another user wants to deposit 1 ether asset, in the function getRsETHAmountToMint calculate the rsETH he will get. In rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice(); rsethAmountToMint = 1ether * 1ether / 1e36 = 1wei , this user deposit 1 ether but gets 1 wei. So do the later depositors.

   Tools Used

   manual

Recommended Mitigation Steps

Add a variable to record the deposit asset to identify the direct transfer asset and deposit assset.

Assessed type

Oracle

[c4-pre-sort]

raymondfam marked the issue as sufficient quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #42

[c4-judge]

fatherGoose1 marked the issue as satisfactory