Thread by @adrianhetman

1/ Do you think ERC20 approve() is safe? Well… 🧵

Function in itself is safe but there are two scenario where ERC20 approve() shows its rough edges.

First is a front-running attack on approve().

Imagine following scenario 👇

2/
* Alice approves Bob for 20 Tokens
* After some time, Alice changes approve to 10
* Bob front-runs the Alice TX for approve(10)
* Bob spends 20 Tokens
* Alice TX passes
* Bob spends additional 10 Tokens from Alice.

Why is that?

3/ Attack is also possible because approve() overrides current allowance.

It doesn’t increase/decrease allowance in atomic manner.

How can we limit against that?

There are two approaches to limit the attack vector.

4/ First:

Send one transaction setting allowance to 0, reseting the allowance for Bob.

The second transaction is approve of the new desired amount.

Main issue is Alice needs two perform two transaction losing costs on gas prices.

Second…

5/ Utilize non-standard functions like increaseAllowance and decreaseAllowance.

These functions are part of standard OpenZeppelin ERC20 implementation.

These non-standard functions are increasing and decreasing allowance as an atomic operation through simple trick.

6/ Instead of sending final value we are interested in, we send current allowance with desired change in value.

Bob can still front-run first approve but with increaseAllowance, he can only claim the change in value.

Instead of setting 30 as new value, we set 10 as new value

7/ Similar with decreaseAllowance.

Bob can still front-run first approve, but when he claims all 20 tokens, Alice’s TX with decreaseAllowance will revert due to subtraction from 0.

That’s for front-running approve.

What about the second issue I mentioned in the begging?

8/ Many projects requires you to approve their smart contracts for some operations.

Uniswap requires approve() so they can execute the transaction instead of you directly sending the tokens.

When you want to swap X token for Y, you need to approve Uniswap to perform the trade.

9/ Often times people approve more than they are spending. For example

approve(uint256(-1))

That approves the maximum value of uint, which is 2^256.

If you would do this on Uniswap, that’s ok as it is a trusted and verified project.

What about new projects?

10/ The issue is if we do the same for the protocol that just has launched or don't have all contracts verified on etherscan.

This time we don't know what exactly is happening, and we can't check the code logic.

What can happen if we did that for malicious contract? Scenario👇

11/
* Alice approves max uint of DAI to new AMM contracts
* Projects does a rug pull
* Steals all the money from the pools
* Steals money from Alice’s wallet as contract have unlimited allowance from Alice for their DAI.

Looks scary and not probable. But does it really? 🍿🤯

12/ That’s exactly what has happened today to StableMagnet.

I won’t go into the details as @RektHQ did a great write-up of the whole situation.

rekt.news/stablemagnet-r…

How can we protect ourselves from situation like 13this?

13/ Approve only the amount you want to spend on the protocol.

You never know what lurks in the dark and if contracts can be trusted.

During a hack, revoke all your allowance on the project.

DeFi contains a lot of predators. Be aware of them and always do your own diligence.

14/ If you want to read in details about the above ERC20 approve issue, please check out my newest blog post.

adrianhetman.com/unboxing-erc20…

I give more details examples to help you understand the issue.

#Ethereum #ERC20 #DeFi

TLDR:
* front-run attack can be done on second approve() tx
* double-spend is possible due to above
* increase/decrease allowance from OZ limits the attack
* never approve unlimited amounts of token to the contract

If you like my content , you can subscribe to 📬 on my blog 👆