Open c4-bot-2 opened 5 months ago
Technically valid, and it doesn´t pose a risk due to sending ETH to a contract is shooting own foot.
@howlbot reject
Hey @koolexcrypto,
This finding was misjudged and missed to be moved to the finding repo.
It is the same as:
Please move it and make it a valid duplicate of https://github.com/code-423n4/2024-05-loop-findings/issues/33.
Hi @radeveth
This should be moved to the main repo since it is a valid issue.
@howlbot undo reject
sorry @0xSorryNotSorry, that command failed
@howlbot accept
Lines of code
https://github.com/code-423n4/2024-05-loop/blob/40167e469edde09969643b6808c57e25d1b9c203/src/PrelaunchPoints.sol#L263
Vulnerability details
Description
According to the NatSpec comment of the
receive()
function: "ETH sent to this contract directly will be locked forever." - all ethers sent directly to the contract should be locked forever. However, ETH sent directly to the contract won't be locked forever but will be distributed among users who have locked ETH. The logic for distribution is insufficient though. A malicious user can frontrun the first user who tries to claim his tokens. The attacker claims a ERC20 token and this way the he will receive all of the locked ethers to himself.Link
Impact
Malicious user can steal all other users' locked ethers.
Proof of Concept
claim()
for ETH and receives all the locked ethers.Tools Used
Manual Review
Recommended Mitigation Steps
Calculate the amount of shares the user should receive instead of transferring the whole balance of the contract to the user.
Assessed type
ETH-Transfer