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

User can manipulate locking mechanism by locking small amount of wrapped `LRT` then send the rest of the ethers at the claim date

howlbot-integration opened this issue · 4 comments

Lines of code

https://github.com/code-423n4/2024-05-loop/blob/0dc8467ccff27230e7c0530b619524cc8401e22a/src/PrelaunchPoints.sol#L262-L263

Vulnerability details

Summary

The Prelaunch Points system will lock fund of the users for at least
7 days after the authorized owner of the smart contract set
the lpETH via setLoopAddresses() function. Within that period,
the users can withdraw their fund. If the users withdraw their
fund, they can't claim lpETH anymore. But this mechanism can be manipulated
by only locking small amount of wrapped LRT and then send the rest of
the fund (in the form of ethers) at the time the users claim the lpETH.
Within the locking and before claim period, the users can use the rest of
their fund to do something else.

Vulnerability Detail

User locks small amount of wrapped LRT. When the claim date comes,
before calling claim() function, the user sends ethers to the contract.
When the claim() function is called, all of its balance will be converted into
lpETH (including the ethers sent by the user).

https://github.com/code-423n4/2024-05-loop/blob/0dc8467ccff27230e7c0530b619524cc8401e22a/src/PrelaunchPoints.sol#L262-L263

Now the user has lpETH from conversion of the amount of locked wrapped LRT plus the
amount of ethers sent.

Impact

The user can manipulate locking mechanism by locking a small amount of wrapped LRT
and provide the rest of the ethers at the claim date to get lpETH.

Code Snippet

https://github.com/code-423n4/2024-05-loop/blob/0dc8467ccff27230e7c0530b619524cc8401e22a/src/PrelaunchPoints.sol#L262-L263

Tool used

Manual Review

Recommendation

Only deposit the amount of ethers bought from exchange when user uses wrapped LRT in order to claim lpETH.

Assessed type

Other

koolexcrypto marked the issue as duplicate of #6

koolexcrypto marked the issue as duplicate of #33

koolexcrypto changed the severity to 3 (High Risk)

koolexcrypto marked the issue as satisfactory