NFTBridge
60,000 USDC
View results
Submission Details
Severity: low
Invalid

Re-Organization Vulnerability in ERC721 Contract Deployment Function: Risks and Mitigation Strategies.

Summary

The vulnerability is related to a potential re-organization (re-org) attack in a smart contract function responsible for deploying
an ERC721 token. The function deployERC721Bridgeable creates a new instance of an ERC721 token and deploys it using the ERC1967Proxy pattern.
However, the deployment process is susceptible to a re-org, which can have serious security implications.

Vulnerability Details

In the provided deployERC721Bridgeable function, a new instance of an ERC721Bridgeable token is deployed, and its initialization data
is encoded and passed to ERC1967Proxy. The function is designed to return the address of the newly deployed proxy contract.

A blockchain re-organization (re-org) can occur when two or more competing blocks are produced simultaneously, leading to one chain
being discarded in favor of another. If a re-org happens after this function is executed, but before the transaction is confirmed
in the final block, the deployment process can be disrupted.

If a re-org occurs, the contract deployment could be rolled back, leading to a situation where the deployERC721Bridgeable function returns
an address that no longer points to a valid contract. This could cause downstream contracts or users to interact with an address
that doesn’t contain the expected contract logic, leading to potential loss of funds, broken functionality, or other security vulnerabilities.

Poc:

function _deployERC721Bridgeable(
string memory name,
string memory symbol,
snaddress collectionL2,
uint256 reqHash
) internal returns(address) {
address proxy = Deployer.deployERC721Bridgeable(name, symbol); // <- Found
_l1ToL2Addresses[proxy] = collectionL2;
_l2ToL1Addresses[collectionL2] = proxy;
emit CollectionDeployedFromL2(reqHash, block.timestamp, proxy, snaddress.unwrap(collectionL2));
return proxy;
}

Impact

The impact of this vulnerability can be severe, especially in a system where the correctness of contract addresses is critical.
If a re-org results in an invalid or non-existent contract address being returned:

Tools Used

Recommendations

Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

invalid-reorg-attack-create

`_l1ToL2Addresses` and `_l2ToL1Addresses` can only be set by the bridge owner or at the deployment in `withdrawTokens`. Even if there is a reorg, the contract will be deployed on a new address which won’t change anything to bridge tokens. No impact.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.