Incorrect Validation in OwnershipNFTs.sol Prevents Valid NFT Transfers and Allows Invalid Ones #96
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
downgraded by judge
Judge downgraded the risk level of this issue
duplicate-148
🤖_09_group
AI based duplicate group recommendation
satisfactory
satisfies C4 submission criteria; eligible for awards
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-08-superposition/blob/4528c9d2dbe1550d2660dac903a8246076044905/pkg/sol/OwnershipNFTs.sol#L93
Vulnerability details
Impact
The bug in the
safeTransferFrom
function of theOwnershipNFTs
contract leads to two critical issues:Denial of Service for Contracts with Correct Implementation: If the recipient (
_to
address) is a contract that correctly implements theonERC721Received
function, the transfer will revert. The root cause is an incorrect conditional check that causes the transfer to fail, even when the contract correctly returns theonERC721Received
function selector. This results in a denial of service (DoS) for valid recipient contracts, preventing them from receiving NFTs.Transfer to Incorrectly Implemented Contracts: Conversely, contracts that do not correctly implement the
onERC721Received
function or return arbitrary values can pass the flawed validation. This means NFTs can be mistakenly transferred to contracts that are not designed to hold NFTs, potentially leading to a loss of assets or other unforeseen consequences due to incorrect handling of NFTs.These issues have significant implications for the integrity and reliability of the NFT transfer process, impacting both security and user trust in the system.
Severity
Proof of Concept
Here is a simplified proof of concept (PoC) demonstrating the issue with the
OwnershipNFTs
contract:1.
Test.t.sol
2.
SeawaterAMM.sol
3.
ISeawaterAMM.sol
4.
IERC721TokenReceiver.sol
Detailed Explanation:
Test Setup:
MockContract
) is created to simulate a valid contract capable of receiving NFTs.OwnershipNFTs
contract is deployed, which is the contract under test, containing the erroneoussafeTransferFrom
function.Test Execution:
test_safetranser()
function, we attempt to transfer an NFT to the mock contract (MockContract
) using thesafeTransferFrom()
function.MockContract
correctly implements theonERC721Received
function and returns the expected function selector (IERC721TokenReceiver.onERC721Received.selector
), the transfer should succeed.Error Encountered:
_onTransferReceived
function:!=
(not equal), meaning that even when the correct function selector is returned, the transfer is rejected, causing the transaction to revert with the message "bad nft transfer received data".Impact:
Test Result
This test fails due to incorrect validation in the
safeTransferFrom
function. Even though the mock contract returns the correct function selector, the transfer reverts, blocking the valid transfer.This result highlights the Denial of Service (DoS) issue, with the
safeTransferFrom
function reverting due to faulty logic.Tools Used
Recommended Mitigation Steps
To resolve this issue, the validation logic in the
_onTransferReceived
function should be corrected. Specifically, the condition checking the return value ofonERC721Received
should be updated to ensure that the function succeeds only when the correct function selector is returned.Updated Code
Explanation of the Fix:
!=
, which caused valid transfers to fail.==
, so the function only reverts if the return value is not the expected function selector (IERC721TokenReceiver.onERC721Received.selector
).onERC721Received
function can receive NFTs, preventing denial of service attacks for valid contracts and improper transfers to incorrect ones.Additional Considerations:
Conclusion
This bug in the
safeTransferFrom
function is critical as it prevents valid transfers and allows potential transfers to contracts without proper NFT handling. The proposed fix resolves this issue by correcting the validation logic, ensuring that only contracts with the correct implementation can receive NFTs. It is strongly recommended to implement this fix to prevent further denial of service or security vulnerabilities in the system.Assessed type
DoS
The text was updated successfully, but these errors were encountered: