Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HolographERC721.safeTransferFrom not compliant with EIP-721 #203

Open
Tracked by #88
code423n4 opened this issue Oct 24, 2022 · 2 comments
Open
Tracked by #88

HolographERC721.safeTransferFrom not compliant with EIP-721 #203

code423n4 opened this issue Oct 24, 2022 · 2 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working responded The Holograph team has reviewed and responded selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/24bc4d8dfeb6e4328d2c6291d20553b1d3eff00b/src/enforcer/HolographERC721.sol#L366

Vulnerability details

Impact

According to EIP-721, we have the following for safeTransferFrom:

///  (...) When transfer is complete, this function
///  checks if `_to` is a smart contract (code size > 0). If so, it calls
///  `onERC721Received` on `_to` and throws if the return value is not
///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.

According to the specification, the function must therefore always call onERC721Received, not only when it has determined via ERC-165 that the contract provides this function. Note that in the EIP, the provided interface for ERC721TokenReceiver does not mention ERC-165. For the token itself, we have: interface ERC721 /* is ERC165 */ {
However, for the receiver, the provided interface there is just: interface ERC721TokenReceiver {
This leads to failed transfers when they should not fail, because many receivers will just implement the onERC721Received function (which is sufficient according to the EIP), and not supportsInterface for ERC-165 support.

Proof Of Concept

Let's say a receiver just implements the IERC721Receiver from OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721Receiver.sol
Like the provided interface in the EIP itself, this interface does not derive from EIP-165. All of these receivers (which are most receivers in practice) will not be able to receive those tokens, because the require statement (that checks for ERC-165 support) reverts.

Recommended Mitigation Steps

Remove the ERC-165 check in the require statement (like OpenZeppelin does: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol#L436)

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Oct 24, 2022
code423n4 added a commit that referenced this issue Oct 24, 2022
@gzeoneth gzeoneth added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Oct 31, 2022
@alexanderattar
Copy link

This will be updated to be fully ERC721 compliant

@alexanderattar alexanderattar added the responded The Holograph team has reviewed and responded label Nov 8, 2022
@trust1995
Copy link

Enjoyed the finding

@CloudEllie CloudEllie added the selected for report This submission will be included/highlighted in the audit report label Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working responded The Holograph team has reviewed and responded selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

5 participants