Closed code423n4 closed 1 year ago
0xA5DF marked the issue as low quality report
PoC not clear enough (doesn't work when pasting into the tests file)
Anyways my guess is that this is due to the free allowance given to minter, this is not an issue
hansfriese marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-04-frankencoin/blob/main/contracts/ERC20.sol#L108 https://github.com/code-423n4/2023-04-frankencoin/blob/main/contracts/ERC20.sol#L125
Vulnerability details
Impact
allowance doesn't get updated properly therefore an attacker contract can exploit the token contract by transferring some tokens and still spend the same amount of allowance. Here are the steps:
calling approve function from ERC20.sol with the spender address of test contract and uint256 value of 69664845694367813355683965970930918025071475522667657600662649263997801130727
and then calling the function transferFrom(address sender, address recipient, uint256 amount) from ERC20.sol with these inputs : sender: msg.sender recipient: 0xdeadbeef amount : 1 the allowance after should be equal to the allowance before minus the transfer amount which in this case is one. but in this case the result is not compliance to this assertion.
Proof of Concept
approve(test contract address,69664845694367813355683965970930918025071475522667657600662649263997801130727) from: https://github.com/code-423n4/2023-04-frankencoin/blob/main/contracts/ERC20.sol#L108
test_ERC20external_spendAllowanceAfterTransfer function from test contract(can be an attacker contract) :
Call sequence: 1.approve(0xa329c0648769a73afac7f9381e08fb43dbea72,69664845694367813355683965970930918025071475522667657600662649263997801130727) 2.test_ERC20external_spendAllowanceAfterTransfer(0xdeadbeef,0)
Event sequence: Panic(1): Using assert., LogUint256(«transfer_value: », 1) from: 0xa329c0648769a73afac7f9381e08fb43dbea72, LogUint256(«current_allowance: », 69664845694367813355683965970930918025071475522667657600662649263997801130727) from: 0xa329c0648769a73afac7f9381e08fb43dbea72, Transfer(1) from: 0xb4c79dab8f259c7aee6e5b2aa729821864227e84, LogUint256(«token.allowance :», 69664845694367813355683965970930918025071475522667657600662649263997801130727) from: 0xa329c0648769a73afac7f9381e08fb43dbea72, LogUint256(« current_allowance - transfer_value:», 69664845694367813355683965970930918025071475522667657600662649263997801130726) from:0xa329c0648769a73afac7f9381e08fb43dbea72, AssertEqFail(«Invalid: 69664845694367813355683965970930918025071475522667657600662649263997801130727!=69664845694367813355683965970930918025071475522667657600662649263997801130726, reason: Allowance not updated correctly») from: 0xa329c0648769a73afac7f9381e08fb43dbea72
Tools Used
echidna
Recommended Mitigation Steps