The 2-step protection used for transactions such as using GMX is not applicable in the function to perform a token "swap."
Some functions are vulnerable to front-running attacks and emergencyClose()
can be denied.
The damage of the front-running type attack is well known, but what could the damage be in our scenario.
For example, if for any reason they want to close the vault, you call emergencyClose()
in GMXEmergency.sol
, to try to return the money, but if you need more TokenA or TokenB tokens, you must make an swap for make the repay, and the key is in the parameters that are used.
So the protocol needs to exchange a token A -> B (or vice versa), because the amount is not enough.
Since _swapNeeded
is true, have to go through this conditional to perform the swap:
The attacker can manipulate the price before the swap by causing it to exceed the slippage limit and reverse it.
If the "slippage" continues to increase to avoid the attacker, it may result in the token used to make the swap being less than the amount needed to make the repay after the swap is made.
This then gives the attacker the opportunity to see the "slippage" and amount of the secondary token before the function is executed to attack and prevent the vault from being closed.
High, the result is that the vault cannot be closed and users cannot perform emergencyWithdraw()
and lending vaults not getting paid back.
Manual Code Review
A good option is to use the exchange mechanism on GMX with 2 steps for the transaction.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.