Exposure to Market Volatility and MEV Risks Due to Absence of User-Defined Deadlines in swapExactOut() Transactions

[c4-bot-6]

Lines of code

https://github.com/code-423n4/2024-01-decent/blob/main/src/swappers/UniSwapper.sol#L153

Vulnerability details

Issue

In function swapExactOut() in UniSwapper.sol, it also does not allow users to supply their own deadline, as the deadline parameter is simply passed in currently as block.timestamp, in which the transaction occurs. This effectively means, that the transaction has no deadline; which means that a swap transaction may be included anytime by validators and remain pending in mempool, potentially exposing users to sandwich attacks by attackers or MEV bots.

Impact

User can face loss of funds due to sandwich attack or MEV attack

Proof of Concept

In the Decent project, specifically within the UniSwapper.sol contract's swapExactOut() function, a significant risk scenario can arise due to the absence of a user-defined deadline for transactions. Let's consider a practical example to illustrate this vulnerability:

Alice, a user of the Decent platform, decides to execute a token swap using the swapExactOut() function. Her goal is to exchange 30 units of a token, say Token A, for a precise amount of another token, Token B, with the minimum amount she is willing to accept being 0.99 units of Token B. The swapExactOut() function in UniSwapper is structured to facilitate this kind of trade, ensuring that Alice receives at least the minimum amount of Token B she has specified.

However, a critical aspect of the swapExactOut() function is that it internally uses block.timestamp as the deadline for the transaction, effectively meaning that the transaction lacks a real deadline. Alice proceeds with her transaction, but she selects a gas fee that is relatively low, causing her transaction to remain pending in the mempool for an extended duration, potentially lasting from hours to weeks.

During this waiting period, the market conditions fluctuate significantly. The value of Token A, which Alice is trading, decreases. Meanwhile, a MEV (Miner Extractable Value) bot, scanning the mempool for profitable opportunities, notices Alice's pending transaction. The bot observes that the outdated minOutput value Alice provided now permits a considerable amount of slippage due to the market changes.

Capitalizing on this opportunity, the MEV bot orchestrates a sandwich attack. It executes transactions strategically around Alice's swap, exploiting the slippage and making a profit at Alice's expense. By the time Alice's transaction is eventually processed, the market value of Token B has changed, and although she receives the 0.99 units of Token B as initially intended, the value of these tokens in terms of her original asset (Token A) is substantially lower than expected. This unfavorable outcome could have been mitigated if a deadline had been set for her transaction, potentially causing it to expire and be cancelled if not executed within a suitable timeframe.

This scenario highlights the risks inherent in not allowing users to specify their own deadlines in swap transactions. The lack of a deadline exposes users to the volatility of the crypto market and the predatory strategies of MEV bots, leading to potentially significant financial losses.

Tools Used

Manual Review

Recommended Mitigation Steps

Allow users to supply their own deadline parameters within the stated functions. The deadline modifier can then be checked via a modifier or check, which has already been implemented via the checkDeadline() modifier.

Assessed type

MEV

[c4-pre-sort]

raymondfam marked the issue as insufficient quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #24

[c4-judge]

alex-ppg marked the issue as unsatisfactory: Invalid