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

Create methods are suspicious of the reorg attack

Summary

Failure to withdraw tokens

https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/ethereum/src/token/Deployer.sol#L37

https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/ethereum/src/token/Deployer.sol#L53

Vulnerability Details

The protocol is deploying NEW NFT bridging contracts using ERC1967 proxy , The issue is that when users rely on the address derivation in advance or try to deploy the position clone with the same address on different EVM chains, any funds sent to the new contract could potentially be withdrawn by anyone else. All in all, it could lead to the theft of user collection.

Although the system is intended to be deployed on Ethereum, there still have been instances of chain reorgs in its PoS era : ref.

Chain reorgs are very prevalent in Ethereum mainnet, we can check this index of reorged blocks on etherscan

function deployERC721Bridgeable(
string memory name,
string memory symbol
)
public
returns (address)
{
address impl = address(new ERC721Bridgeable());
bytes memory dataInit = abi.encodeWithSelector(
ERC721Bridgeable.initialize.selector,
abi.encode(name, symbol)
);
return address(new ERC1967Proxy(impl, dataInit));
}
.....
function deployERC1155Bridgeable(
string memory uri
)
public
returns (address)
{
address impl = address(new ERC1155Bridgeable());
bytes memory dataInit = abi.encodeWithSelector(
ERC1155Bridgeable.initialize.selector,
abi.encode(uri)
);
return address(new ERC1967Proxy(impl, dataInit));
}

Assume user1 wants to withdraw their specific set of NFT from L2, they initiate the withdrawal of that particular collection. Another user2 who keeps eyes on the mempool sees a block reorg happening, and calls the deployBridge contract which creates NEW NFT bridging contracts Now user1 withdrawal happens and his collection is sent to thE NFT contract controlled by user2

Impact

Failure to withdraw from contract due to block reorg

Tools Used

Manual Review

Recommendations

Deploy such contracts via create2 with salt that includes msg.sender.

Updates

Lead Judging Commences

n0kto Lead Judge 9 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.