howlbot-integration[bot] commented 4 months ago

Lines of code

https://github.com/code-423n4/2024-05-loop/blob/40167e469edde09969643b6808c57e25d1b9c203/src/PrelaunchPoints.sol#L179-L182 https://github.com/code-423n4/2024-05-loop/blob/40167e469edde09969643b6808c57e25d1b9c203/src/PrelaunchPoints.sol#L321-L322

Vulnerability details

Impact

The contract is designed to receive ETH so that users can use the function lockETH() to get lpETH (1 to 1 conversion). User deposits are stored in the state variable totalSupply. While converting all user deposited ETH to lpETH via a privileged function convertAllETH(), the ETH balance of the current contract is used instead of the state variable totalSupply. In case that some users mistakenly sent ETH directly to the contract the 1 to 1 conversion ratio of ETH to lpETH will be broken leading to users getting more lpETH than they were supposed to.

Proof of Concept

Consider all user ETH deposits in the state variable is 1000.
Someone mistakenly had sent 10 ETH directly to the contract.
totalBalance variable in the function convertAllETH() will be 1010 resulting in minting of 1010 lpETH. totalLpETH state variable will be also 1010.
While user is claiming lpETH, the following formula is used claimedAmount = userStake.mulDiv(totalLpETH, totalSupply);

In this situation, all users will get 1.01 more lpETH that the ETH they staked. It will be more if the amount of ETH that was mistakenly sent is higher.

Tools Used

Manual review.

Recommended Mitigation Steps

Use state variable totalSupply in the function convertAllETH instead of "address(this).balance" to calculate the amount to be deposited to lpETH contract.

Assessed type

Invalid Validation

c4-judge commented 4 months ago

koolexcrypto marked the issue as duplicate of #6

c4-judge commented 4 months ago

koolexcrypto marked the issue as partial-50

c4-judge commented 4 months ago

koolexcrypto marked the issue as not a duplicate

c4-judge commented 4 months ago

koolexcrypto marked the issue as primary issue