Method `decreaseApproval` in unsafe

[3sGgpQ8H]

Method decreaseApproval in StandardToken.sol is unsafe. Here is the scenario.

1. Bob is allowed to transfer zero Alice's tokens
2. Alice allows Bob to transfer 100 of here tokens via approve or increaseApproval method and transaction is executed successfully
3. Alice sees that Bob is now allowed to transfer 100 of her tokens
4. After some time, Alice uses decreaseApproval method to decrease by 100 the number of her tokens Bob is allowed to transfer and transaction is executed successfully and proper Approval event was logged
5. Alice sees that Bob is allowed to transfer 0 of her tokens
6. Now Alice may think that once decreaseApproval call was executed successfully, then Bob didn't manage to transfer any of her tokens before the allowance was decreased, but this assumption is wrong.
   Actually, Bob may or may not had transferred Alice's tokens before allowance was decreased, and Alice has no easy way to know for sure whether Bob transferred her tokens or not

Method decreaseApproval should fail in case current allowance is lower than requested decrease.

[frangio]

Hi @mikhail-vladimirov, thanks for reporting! (And thanks for the overall thorough review.)

I thought about this and I'm not sure I agree with either the risk or the proposed mitigation. At point 4, once Alice sees her call succeeded, she would be able to see any Transfer events if Bob had managed to make a transfer, and in fact she would see her own reduced balance.

Furthermore, suppose we changed decreaseApproval to fail if allowance was lower than the request decrease. If Alice attempts to decrease Bob's allowance to zero, and Bob manages to transfer half of his allowance before the decrease, the call to decreaseApproval would fail and then Bob would be able to spend the other half! This is in my opinion worse than the current risk. What do you think?

[3sGgpQ8H]

she would be able to see any Transfer events if Bob had managed to make a transfer

If Bob had transferred Alice's tokens to Carol, not to himself. it would be very non-trivial to know that this transfer was done by Bob, not Carol.

Bob would be able to spend the other half!

Bob anyway had a chance to get all the allowed tokens, and he had this ability for a long time, nothing bad if he will be able to do this for little more time. Bad thing is not that Bob is able to get tokens, this is actually normal, because Alice herself allowed him to do this. Bad thing is that after changing the allowance, Alice does not know how much of the original allowance was actually used by Bob, and thus does not know how much tokens she owes Bob, or Bob owes her; so Bob may actually cheat Alice by pretending that he didn't use any allowance (thus Alice still owes some tokens to Bob) while he actually did use it.

So safe decreaseApproval method should succeed only if allowance was actually decreased exactly by desired number of token, not by some other number. If Alice just wants to revoke all the allowance from Bob as fast as possible, she will use approve method to set allowance to zero.

[frangio]

If Bob had transferred Alice's tokens to Carol, not to himself. it would be very non-trivial to know that this transfer was done by Bob, not Carol.

This is a different problem that I completely agree with, which is the lack of a spender parameter in Transfer events. We could add a new event that allows to keep track of this, it's a pity that there isn't a standard one.

Bob anyway had a chance to get all the allowed tokens, and he had this ability for a long time, nothing bad if he will be able to do this for little more time.

Suppose "Bob" is a smart contract that is programmed to make a transfer with a certain frequency and you want to stop it immediatey. I agree that approve with zero is the correct thing to do here, but it may not be immediately apparent from the function signatures and someone might use decreaseApproval.

I share some of the concerns but I think most of the risk can be mitigated by logging how much an approved spender has transferred. Do you agree?

I'm open to hearing more opinions though. Have you reported this elsewhere?

[3sGgpQ8H]

There are absolutely no problems with Bob being able to transfer as many tokens as Alice approved to him until Alice revoked the approval. This is how token contracts are supposed to work. Regardless of what Bob does, once Alice approved some tokens to Bob, she approved, and it is her full responsibility to make sure Bob is a good guy before approving anything to him.

The real problems with ERC20 are:

1. In some cases Bob may transfer MORE Alice's tokens than Alice ever intended to approve to him. For example, Alice approved 100 token, then she wanted to change this to 101. While Alice never intended to allow Bob to transfer more than 101 of her tokens, Bob may actually transfer 201 which is really bad.
2. In some cases Bob may transfer as many Alice's tokens as Alice approved to him (which is fine) but may make it look like he didn't transfer them (which is really bad). Thus Bob may, for example, avoid paying Alice for tokens he actually got from her.

In current form, decreaseApproval addresses the first problem but didn't address the second one which is only slightly less dangerous.

[jakub-wojciechowski]

Hi Guys, I've enjoyed reading the discussion. Thx, for pointing out the vulnerability @mikhail-vladimirov!

Currently we have a soft condition requiring that the deduction is lower than allowance or the allowance is reduced to zero. How about making it stronger and requesting that the current allowance is equal to a state known by transaction sender.

function decreaseApproval (address _spender, uint _decreaseFrom, uint _decreaseBy)
...
require(allowed[msg.sender][_spender] == _decreaseFrom);

Using this approach we will make it sure that the operation exactly satisfies the intentions of the sender and the current state of the contract matches state know by the sender. It will also make the whole process of allowance update atomic and prevent race conditions. Actually, the proposed design will be a form of Compare and Swap pattern which is widely used in concurrency programming.

[3sGgpQ8H]

This should work, but in this case you probably need to remove "decrease" from the method name and make it able to change allowance in either direction.

[frangio]

I like @jakub-wojciechowski's proposal because it does make the semantics quite apparent from the function signature. I feel like I've seen the Compare and Swap function proposed before as a solution to the approve race condition.

[jakub-wojciechowski]

I'm really glad that you liked it. I'm certainly not the one to take credit for the Compare and Swap pattern as it's one of the most widely used lock-free synchronisation strategy and probably older than me :)

I agree with @mikhail-vladimirov that it'd be better to merge both decreaseApproval and increaseApproval in single method. What's your view on that @frangio ?

[3sGgpQ8H]

Here is an example of compare and set approve function in ERC20 token smart contract: https://github.com/abdk-consulting/icos-token-contract/blob/master/src/sol/ICOSToken.sol#L106

[SylTi]

@mikhail-vladimirov that example is not ERC20 compliant.

This should also be taken into account #438

[3sGgpQ8H]

that example is not ERC20 compliant

It is compliant with original ERC20. It does not strictly comply with EIP-20 though, because it was created before EIP-20 was finalized.

[SylTi]

it's been a while that approve only took 2 parameters in the draft

[3sGgpQ8H]

Oh, now I see what did you mean when said that contract I referred to is not ERC20 compliant. Of cause that contract has standard two-argument approve method as well, you probably just didn't noticed it because it is defined in base contract that contract inherits from: https://github.com/abdk-consulting/icos-token-contract/blob/master/src/sol/AbstractToken.sol#L83

[frangio]

I'd go ahead with a CAS function. What should we name it? It's technically possible to call it approve with three parameters but it could be confusing.