Closed code423n4 closed 1 year ago
The system is designed to work only with compliant ERC721s. Our ERC20 solution already works with all major ERC20s that are both compliant and non-compliant. We don't think it's worth accommodating extremely broken ERC20s.
Although this may not be required / relevant, and the report does not include concrete examples to justify the severity - it's a valid suggestion to consider to potentially be more robust. Lowering risk and merging with the warden's QA report #348
Lines of code
https://github.com/PartyDAO/party-contracts-c4/blob/d129d647796369a18e30b336e74e7d1bfc779597/contracts/utils/LibSafeERC721.sol#L16 https://github.com/PartyDAO/party-contracts-c4/blob/d129d647796369a18e30b336e74e7d1bfc779597/contracts/utils/LibERC20Compat.sol#L12
Vulnerability details
Description
There is
safeOwnerOf
function in theLibSafeERC721
contract andcompatTransfer
function in theLibERC20Compat
contract. Both of them are designed in a way to be compatiable with incorrect implementation of the contract to be called.safeOwnerOf
even declared to proceed without reverting in any case. But both of them reverting onabi.decode(...)
when the data returned from the call can't be correctly decoded into the specified type.Proof of Concept
Recommended Mitigation Steps
Use assembly instructions for decoding the result or add special checks on the returned bytes array.