Repaying debt can be sandwich-attacked

[code423n4]

Handle

@cmichelio

Vulnerability details

Vulnerability Details

When debt is repaid the Router.repayForMember function performs a swap to buy back debt:

iPOOLS(POOLS).swap(VADER, debtAsset, address(this), true);

A swap of large trade order size can be sandwich-attacked as it does not have any slippage protection.

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.

Impact

Using this tactic an attacker can potentially make a profit and the attacker's profit is the protocol reserve's loss.

Recommended Mitigation Steps

One may not trust that the current pool spot price reflects the market price. Could use TWAP oracles and have a slippage parameter that is compared against the TWAP price.

[strictly-scarce]

Sandwich attacks don't work with slip-based fees, since the attacker pays more than they can gain by moving up and then back down.

[Mervyn853]

Our decision matrix for severity:

0: No-risk: Code style, clarity, off-chain monitoring (events etc), exclude gas-optimisations 1: Low Risk: UX, state handling, function incorrect as to spec 2: Funds-Not-At-Risk, but can impact the functioning of the protocol, or leak value with a hypothetical attack path with stated assumptions, but external requirements 3: Funds can be stolen/lost directly, or indirectly if a valid attack path shown that does not have handwavey hypotheticals.

Recommended: 0