search

code-423n4 / 2023-01-numoen-findings

0 stars 0 forks source link

Lack of slippage protection when swapping on Uniswap v2/v3 #216

Closed code423n4 closed 1 year ago

code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-01-numoen/blob/2ad9a73d793ea23a25a381faadc86ae0c8cb5913/src/periphery/SwapHelper.sol#L87-L88 https://github.com/code-423n4/2023-01-numoen/blob/2ad9a73d793ea23a25a381faadc86ae0c8cb5913/src/periphery/SwapHelper.sol#L103-L109

Vulnerability details

Impact

Lack of slippage protection when swapping on Uniswap v2/v3. It'll create the potential to be sandwiched by MEV bots and result in user loss.

Proof of Concept

In the LendgineRouter.mint() function, the contract would swap all the token0 to token1 in mintCallback. In the LendgineRouter.burn() function, the contract would swap token1 to token0 in pairMintCallback

MEV bots can listen to(if they can, like on Ethereum mainnet) transactions like LendgineRouter.mint() calls in the mempool, and sandwich it with 2 swaps:

  1. swap a large amount of token0 to token1
  2. execute the user's tx
  3. swap back token1 to token0

since the price would be manipulated by MEV bot, the user will get a bad swap with little token1 received.

This attack also applies to LendgineRouter.burn() function.

Tools Used

Self-hosted node to listen to the mempool txs. use a gas auction or tools like falshbots to reorder the txs and make the sandwich attack.

Recommended Mitigation Steps

Should add a max swap slippage param for LendgineRouter.mint() and LendgineRouter.burn(), just like what Uniswap router does.

code423n4 commented 1 year ago

Withdrawn by paco