code-423n4/2024-05-loop-findings

Users can claim more lpETH than locked ETH in case of someone sends ETH to the contract directly

howlbot-integration opened this issue · 9 comments

howlbot-integration commented

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

koolexcrypto marked the issue as duplicate of #6

c4-judge commented

koolexcrypto marked the issue as partial-50

c4-judge commented

koolexcrypto marked the issue as not a duplicate

c4-judge commented

koolexcrypto marked the issue as primary issue

c4-judge commented

koolexcrypto marked the issue as satisfactory

c4-judge commented

koolexcrypto changed the severity to 3 (High Risk)

c4-judge commented

koolexcrypto changed the severity to 2 (Med Risk)

c4-judge commented

koolexcrypto changed the severity to 3 (High Risk)

c4-judge commented

koolexcrypto marked the issue as duplicate of #33