No slippage protection in VaderPoolV2.mintSynth

[code423n4]

Handle

cmichel

Vulnerability details

The VaderPoolV2.mintSynth implicitly performs a "native -> foreign" swap using VaderMath.calculateSwap(nativeDeposit,reserveNative,reserveForeign), the resulting amount will be minted as synths instead of transferred out as foreign tokens.

The calculateSwap calculation, therefore, depends on the current reserves and the mintSynth does not allow specifying any minSynthAmount for the caller to make sure that they cannot be sandwich attacked.
It's basically doing a trade with a slippage check always set to 100%.

Impact

Any mintSynth call can be sandwich attacked to make a profit.

A common attack in DeFi is the sandwich attack. Upon observing a trade of asset X for asset Y, an attacker frontruns the victim trade by also buying asset Y, lets the victim execute the trade, and then backruns (executes after) the victim by trading back the amount gained in the first trade. Intuitively, one uses the knowledge that someone’s going to buy an asset, and that this trade will increase its price, to make a profit. The attacker’s plan is to buy this asset cheap, let the victim buy at an increased price, and then sell the received amount again at a higher price afterwards.

• Attacker frontruns mintSynth by performing a standard swap, trading native assets to foreign assets, leading to a worse synth price for the victim
• Victim performs the mint synth, depositing native tokens (receiving synths at a worse price)
• Attacker now sells the received foreign assets from the first step into the increased native reserves for a profit

Trades can happen at a bad price and lead to receiving fewer tokens than at a fair market price.
The attacker's profit is the user's loss.

Recommended Mitigation Steps

Add minimum return amount checks.
Accept a function parameter that can be chosen by the transaction sender, then check that the actually received amount is above this parameter.

[SamSteinGG]

Duplicate #2