Closed code423n4 closed 2 years ago
Copying an issue from a previous audit which has been acknowledged and then disagreeing with the acknowledgement feels like they are trying to game the system.
Above is valid, but moreover this would require approvals from address(0) somehow. Since that wouldnt be a concern, the attack vector isnt really valid.
you could argue that, for QA sake - that method should revert. it is not a threat to our system as @JTraversa explained - any 0x0 is going to be rejected after. however, it's a simple issue to fix and test, so...
Copying an issue from a previous audit which has been acknowledged and then disagreeing with the acknowledgement feels like they are trying to game the system.
Yes I agree here. Downgrading to QA
Grouping this with the warden’s QA report, #165
Lines of code
https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Swivel.sol#L693-L697 https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Sig.sol#L20-L31
Vulnerability details
Impact
The solidity function ecrecover is used, however the error result of 0 is not checked for. See documentation: https://docs.soliditylang.org/en/v0.8.9/units-and-global-variables.html?highlight=ecrecover#mathematical-and-cryptographic-functions “recover the address associated with the public key from elliptic curve signature or return zero on error. ”
Now you can supply invalid input parameters to the Sig.recover function, which will then result 0. If you also set o.maker to be 0 then this will match and an invalid signature is not detected.
So you can do all kinds of illegal & unexpected transactions.
This also found in previous audit: https://code4rena.com/reports/2021-09-swivel/#h-04-return-value-of-0-from-ecrecover-not-checked
Proof of Concept
https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Swivel.sol#L693-L697
https://github.com/code-423n4/2022-07-swivel/blob/daf72892d8a8d6eaa43b9e7d1924ccb0e612ee3c/Swivel/Sig.sol#L20-L31
You have said that "The suggestion would be to filter 0x00 makers from the orderbook? (which we do)" but I don't see where you do.
Tools Used
Recommended Mitigation Steps
Verify that the result from ecrecover isn’t 0