ArkProject: NFT Bridge

Summary

The depositTokens() function in the Bridge contract lacks proper L2 address validation, potentially allowing deposits to invalid or problematic addresses on StarkNet. This oversight could lead to failed transactions, locked tokens, or unexpected behavior in cross-chain transfers.

Vulnerability Details

The depositTokens( ) function in the Bridge contract facilitates the transfer of tokens from L1 to L2. It handles the deposit process for users who want to bridge their NFT to StarkNet.

The first step the function takes is to check if the provided ownerL2 address is a valid felt252 using the Cairo.isFelt252() function:

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

Below is the function Cairo.isFelt252( )

The function checks if the unwrapped value of ownerL2 is a valid felt252 value. It verifies that the given address is within the range of valid StarkNet field element values, which is less than the SN_MODULUS.

This check ensures that the address can be properly represented and processed on the StarkNet L2 network. However it doesn't prevent the use of the zero address or other potentially problematic addresses on StarkNet.

In StarkNet, users do not have addresses in the traditional sense. Transactions sent to the network have the 0 address as the caller. To identify accounts, each user deploys their own account contract. Users then interact with other contracts, such as token contracts, through their account contract

Reference : https://community.starknet.io/t/account-keys-and-addresses-derivation-standard/1230

On StarkNet we have account abstraction which means that the address of an account is computed as a smart contract with no direct relation to the key(s) controlling the account

The current implementation of the depositTokens() function allows users to deposit with the ownerL2 address potentially set to 0. While the function checks if the address is a valid felt252 using Cairo.isFelt252(), it doesn't prevent the use of the zero address.

Users could inadvertently specify the L2 bridge contract as the recipient of the funds on deposit. Since the L1 call would succeed while the L2 call might fail, the cross-layer message could remain unconsumed, leading to locked funds.

Impact

Loss of user funds, as tokens may be sent to invalid or inaccessible address on StarkNet,

Tools Used

Manual Review

Recommendations