Open code423n4 opened 2 years ago
I think "limitSqrtPrice" serves as adequate slippage protection for swaps.
given the lack of periphery contracts that would handle slippage for minting LP tokens, there doesn't appear to be any mechanism to ensure that during mint
or burn
there isn't greater than expected slippage. Will wait for the sponsor to comment on this to confirm my understanding.
If correct, this should be a H severity finding as it does lead to a loss of funds from sandwich attacks
Contracts are initially made taking into account the use of appropriate periphery. Accordingly, slippage control is in the area of responsibility of the periphery.
given that this wasn't made explicit in the README and the scope of the contracts that are being audited is what was provided to the wardens, I believe the wardens issue to be valid.
Yes, its handled in the periphery contracts. But, I will consider it to be a medium risk given we did not update the README file.
The issue is not that the README wasn't updated. The issue is that the contracts that were submitted for audit contain a vulnerability. The wardens spent time and energy to find that vulnerability and it should be awarded. It is good to know you already have a mitigation plan in place, but at the time of the wardens doing their work, they had no way of knowing that.
I believe it's safe for both user as well as for the protocol ...
After more discussions during QA, it was made clear that I missed the fact the the call from an EOA would revert. So a contract must be the caller here, which makes it less likely that this becomes an issue. While I do think the sponsors should have been more explicit in the readme, this brings down potential for this to be a problem considerably.
Given that it was not documented and an integrating contract would have to know that it needed to handle slippage will downgrade to M.
Lines of code
https://github.com/code-423n4/2022-09-quickswap/blob/15ea643c85ed936a92d2676a7aabf739b210af39/src/core/contracts/AlgebraPool.sol#L416-L485 https://github.com/code-423n4/2022-09-quickswap/blob/15ea643c85ed936a92d2676a7aabf739b210af39/src/core/contracts/AlgebraPool.sol#L589-L623 https://github.com/code-423n4/2022-09-quickswap/blob/15ea643c85ed936a92d2676a7aabf739b210af39/src/core/contracts/AlgebraPool.sol#L626-L673
Vulnerability details
Impact
Missing slippage control system. Users may lose a lot of funds due to front-running MEV bots. It has liquidityDesired or amountRequired but these parameters are only used in output amount calculation. It isn't used to prevent the output amounts from dropping below a threshold. So, MEV bots can front-run to profit from dropping the output amount of user swap.
Proof of Concept
liquidityDesired or amountRequired but these parameters are only used in output amount calculation.
(amount0, amount1, currentPrice, currentTick, currentLiquidity, communityFee) = _calculateSwapAndLock(zeroToOne, amountRequired, limitSqrtPrice);
It isn't used to prevent the output amounts from dropping below a threshold. As there aren't any
require(amount1 >= ...)
pattern before/after transferring the output token.It is possible that the output amount is less than the amount desired due to this comment "the amount to get could be less then initially specified (e.g. reached limit)"
Recommended Mitigation Steps
Add minAmountOut parameter and check it before sending the output token.