LoopFi - TheFabled's results

A dedicated lending market for Ethereum carry trades. Users can supply a long tail of Liquid Restaking Tokens (LRT) and their derivatives as collateral to borrow ETH for increased yield exposure.

General Information

Platform: Code4rena

Start Date: 01/05/2024

Pot Size: $12,100 USDC

Total HM: 1

Participants: 47

Period: 7 days

Judge: Koolex

Id: 371

League: ETH

LoopFi

Findings Distribution

Researcher Performance

Rank: 21/47

Findings: 1

Award: $213.33

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

213.3333 USDC - $213.33

Labels

bug
3 (High Risk)
partial-75
sufficient quality report
upgraded by judge
:robot:_42_group
duplicate-33

External Links

Lines of code

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

Vulnerability details

Summary:

The PrelaunchPoints contract currently contains logic that allows users to claim their locked funds as lpETH during a claim period. However, there exists a vulnerability where ETH sent to the contract via direct transfer (fallback function) is not accounted for and may result in more lpETH being minted and potentially staked than intended based on a user's legitimate locked tokens balance.

Description:

In the _claim function, after swapping a user's ERC20 tokens for ETH using _fillQuote, the contract mints lpETH using the entire balance of ETH within the contract, rather than only the amount of ETH that was specifically obtained from the swap. This behavior opens up an opportunity for a user to "front-run" their claim by transferring ETH directly to the contract at the time of calling the claim function, leading to a larger amount of lpETH being minted than is due from their locked ERC20 token balance alone.

Impact:

By sending additional ETH to the contract before claiming, a user can artificially inflate the amount of lpETH that they receive, which could lead to an unfair advantage in the staking process. This may, in turn, distort the staking rewards and undermine the prelaunch point system's integrity and intended economics, leading to possible reputational damage and potential financial loss for legitimate participants.

Steps To Reproduce:
  1. Lock an ERC20 token in the contract that is approved for conversion to lpETH.
  2. Call the claim function with parameters to trade the ERC20 for ETH and then mint lpETH.
  3. Immediately before the claim transaction is mined, send ETH directly to the contract's address, triggering the fallback function.
  4. Observe that the contract uses the entire ETH balance, which includes the additional ETH sent unintentionally, to mint lpETH.
Recommendation:

To mitigate this issue, the contract should clearly track and account for the ETH received solely from the execution of the token swap. Only this amount of ETH should be used for the minting of lpETH. The contract can achieve this by checking the ETH balance before and after the swap transaction, using the difference between these balances for minting:

uint256 preSwapBalance = address(this).balance;
// Execute the token to ETH swap
_fillQuote(IERC20(_token), _amount, _swapCallData);
uint256 postSwapBalance = address(this).balance;
// Calculate ETH obtained from the swap
uint256 swappedETHAmount = postSwapBalance - preSwapBalance;
// Only use the swapped ETH amount for lpETH minting
lpETH.deposit{value: swappedETHAmount}(_receiver);

Implementing these changes would ensure that only the ETH obtained from swapping locked ERC20 tokens is used for claiming, thereby preventing manipulation by front-running with direct ETH transfers to the contract.

Assessed type

Other

#0 - c4-judge

2024-05-15T14:34:42Z

koolexcrypto marked the issue as duplicate of #18

#1 - c4-judge

2024-06-03T09:03:32Z

koolexcrypto changed the severity to 3 (High Risk)

#2 - c4-judge

2024-06-05T07:29:36Z

koolexcrypto changed the severity to 2 (Med Risk)

#3 - c4-judge

2024-06-05T09:18:35Z

koolexcrypto marked the issue as partial-75

#4 - c4-judge

2024-06-05T09:41:00Z

koolexcrypto changed the severity to 3 (High Risk)

#5 - c4-judge

2024-06-05T09:41:14Z

koolexcrypto marked the issue as duplicate of #33

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter