lukso-network
[LSP7] Allowance Double-Spend Exploit in `authorizeOperator(..)`
What this issue is about?
As it presently is constructed, the contract is vulnerable to the allowance double-spend exploit, as with other ERC20/LSP7 tokens.
Exploit Scenario: 1. Alice allows Bob to transfer N amount of Alice's tokens (N>0) by calling the authorizeOperator(..) method on LSP7 smart contract (passing Bob's address and N as method arguments).
After some time, Alice decides to change from N to M (M>0) the number of Alice's tokens Bob is allowed to transfer, so she calls the authorizeOperator(..) method again, this time passing Bob's address and M as method arguments.
Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls the transfer(..) method to transfer N Alice's tokens somewhere.
If Bob's transaction will be executed before Alice's transaction, then Bob will successfully transfer N Alice's tokens and will gain the ability to transfer another M tokens.
Before Alice notices any irregularities, Bob calls the transfer(..) method again, this time to transfer M Alice's tokens.
How to solve?
The front-running problem cannot be mitigated in the blockchain space but some work around can be done at the standard level or smart contract level to eliminate the risk of front-running.
One possible solution could be adding increaseAllowance(..) and decreaseAllowance function alike from ERC20.
Another one could be changing the behavior of authorizeOperator(..) to just add the authorized amount to the last amount present. But the problem will still exist when we want to decrease the allowance of an address.
For now, this risk could be mitigated by calling revokeOperator(..) function first, and then re-calling authorizeOperator with the whole amount we want to authorize the operator for.
To be discussed..
