Possible race condition when using the approve() functionality.

[code423n4]

Lines of code

https://github.com/code-423n4/2023-06-lybra/blob/main/contracts/lybra/token/EUSD.sol#L200-L204
https://github.com/code-423n4/2023-06-lybra/blob/main/contracts/lybra/token/EUSD.sol#L226-L233
https://github.com/code-423n4/2023-06-lybra/blob/main/contracts/lybra/token/EUSD.sol#L153-L157

Vulnerability details

Impact

There is a gap between the creation of a transaction and the moment it is accepted in the blockchain. Therefore, an attacker can take advantage of this gap to put a contract in a state that advantages them.

Proof of Concept

Suppose Alice has approved Bob to spend 100 tokens on her behalf. She then decides to only approve him for 50 tokens and sends a second approve transaction. However, Bob sees that he's about to be downgraded and quickly submits a transferFrom for the original 100 tokens he was approved for. Additionally he prioritizes it by setting a high fee to ensure it gets executed before Alice's second transaction - approve("Bob", 50). If this transaction gets mined before Alice's second approve, Bob will be able to spend 150 of Alice's tokens.

There's a well known vulnerability with front running the approve function as mentioned in the following resources: 1, 2, 3, 4, 5, 6.

Tools Used

Manual Review

Recommended Mitigation Steps

• For the ERC20 bug, insist that Alice only be able to approve Bob when he is approved for 0 tokens.

• Consider use safeIncreaseAllowance and safeDecreaseAllowance.

Assessed type

ERC20

[c4-pre-sort]

JeffCX marked the issue as duplicate of #784

[c4-judge]

0xean marked the issue as unsatisfactory:
Invalid