ArkProject: NFT Bridge

Summary

Bridging multiple instances of worthless ERC-721 collections from the L2 can prevent any new collections from being bridged onto the L1.

Vulnerability Details

The L2 bridge can conditionally whitelist tokens, however by default, the whitelist is disabled, allowing any tokens to be bridged from Starknet to Mainnet. This means it is possible to create a large number of worthless ERC-721 collections and request that these are bridged to the L1.

This becomes an issue when we take into account what happens when a newly-bridged token from the trusted L2 contract is received by the L1 bridge:

When encountering a crosschain message which references an unseen L2 collection address the very first time, _verifyRequestAddresses returns a collectionL1 of address(0), forcing the L1 bridge to execute the logic listed above.

Aside from deploying the proxy ERC-721 bridge contract via deployERC721Bridgeable, the L1 bridge also invokes whiteListCollection:

Notice here that for each new collection we bridge from Starknet, we will have to iterate through a longer and longer list of _collections.

Invariably, an attacker spamming worthless collections will cause this operation to revert through OOG for all subsequent attempts to honestly bridge new collections.

Impact

Denial of service to all subsequent bridged tokens which have not yet been processed.

Tools Used

Manual Review

Recommendations

Although an attacker can trigger this scenario intentionally, over time this will be likely to emerge through honest bridge operations.

Refactor the whitelist implementation to use an EnumerableMap instead, which enables the Bridge to maintain an iterable array of unique collection addresses without needing to loop through all elements upon insertion.

Additionally, consider enforcing the whitelist by default on the L2.