An attacker could front-run an approve() transaction to get an overall bigger amount approved.
Proof of Concept
This is the approve() function of the DBR token.
function approve(address spender, uint256 amount) public virtual returns (bool) {
allowance[msg.sender][spender] = amount;
emit Approval(msg.sender, spender, amount);
return true;
}
The attack path would be:
Bob approves 50 tokens for Alice
Bob wants to change the approval from 50 to 10
Alice front runs the transaction and spends the approval before it's changed.
Alice spends 10 more tokens summing a total of 60 tokens spent.
To sum up, Alice spends 50 tokens, then Bob allows 10 more tokens because the allowance is not checking prior balances, it just changes the actual balance to the amount allowed.
Tools Used
Manual review
Recommended Mitigation Steps
Use non-standard functions of ERC20. increaseAllowance() and decreaseAllowance() .
Lines of code
https://github.com/code-423n4/2022-10-inverse/blob/3e81f0f5908ea99b36e6ab72f13488bbfe622183/src/DBR.sol#L158
Vulnerability details
Impact
An attacker could front-run an approve() transaction to get an overall bigger amount approved.
Proof of Concept
This is the approve() function of the DBR token.
The attack path would be:
To sum up, Alice spends 50 tokens, then Bob allows 10 more tokens because the allowance is not checking prior balances, it just changes the actual balance to the amount allowed.
Tools Used
Manual review
Recommended Mitigation Steps
Use non-standard functions of ERC20. increaseAllowance() and decreaseAllowance() .