ArkProject: NFT Bridge

Summary

Withdrawing atomic batches from escrow may exceed call gas limits.

Vulnerability Details

Due to data processing limits, the Ethereum Bridge contract enforces a MAX_PAYLOAD_LENGTH:

However, no such limit is enforced on the Starknet Bridge counterpart.

This makes it is possible to successfully generate payloads greatly in excess of the MAX_PAYLOAD_LENGTH from the L2 and request these to be handled back on Mainnet.

Furthermore, when we withdrawTokens, all bridged tokens must be redeemed simultaneously:

Notice that each token in the batch must be successfully processed else the entire batch will fail.

If we consider the case of an IERC721Receiver which executes nontrivial business logic via onERC721Received callback, attempting to transfer all tokens at once to the receiver may exceed intended call gas limits and force the entire batch to fail. Likewise, if a single transaction were to fail (e.g. failed receiver validation), then the entire would also result in revert.

Impact

Susceptibility to OOG when withdrawing batches of bridged tokens from the L1 Bridge contract.

Tools Used

Manual Review

Recommendations

Firstly, it is imperative to enforce the invariant maximum payload size on Starknet when creating a payload.

Furthermore, we advise against the "push-payment" strategy when handling L2 payloads, and instead argue in favour of the "pull-payment" technique - receiving the payload at the Bridge L1 destination should merely approvereq.ownerL1 to withdraw the unlocked tokens in one-or-many subsequent transactions. This provides the flexibility to control which subset of tokens should be withdrawn from escrow.

This approach ensures that failures associated with transacting individual tokens, or failures associated with attempting to transact all tokens en masse, can be safely circumvented.