Steadefi

Summary

The standard ERC20 implementation contains a widely-known racing condition in its approve function, wherein a spender is able to witness the token owner broadcast a transaction altering their approval and quickly sign and broadcast a transaction using to move the current approved amount from the owner’s balance to the spender. If the
spender’s transaction is validated before the owner’s, the spender will be able to get both approval amounts of both transactions.

It is also mentioned in the EIP-20:

NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before

More detail see here and here.

Vulnerability Details

There are 2 instances of this issue:

• IERC20(sp.tokenIn).approve(address(self.swapRouter),sp.amountIn) should be used safeIncreaseAllowance() or safeDecreaseAllowance() instead.

• IERC20(sp.tokenIn).approve(address(self.swapRouter),sp.amountIn) should be used safeIncreaseAllowance() or safeDecreaseAllowance() instead.

Impact

Front running attack in approve.

Tools Used

Manual Review

Recommendations

Use OpenZeppelin's increaseAllowance and decreaseAllowance functions to modify the approval amount instead of using the approve() function to modify it.