ArkProject: NFT Bridge

Summary

The Starklane bridge between Ethereum (L1) and Starknet (L2) exhibits potential overconstrained L1 <-> L2 interactions. These asymmetries in validation and functionality between the L1 and L2 sides of the bridge could lead to unexpected behavior, potentially resulting in loss of user funds.

Vulnerability Details

1. Auto-withdraw flag inconsistency:

   1. The L2 deposit_tokens() function allows users to set use_withdraw_auto to true.

   2. However, the L1 withdrawTokens() function rejects requests with this flag set.

2. Asymmetric bridge enablement:

   1. The bridge can be enabled/disabled independently on L1 and L2.

   2. Due to the asynchronous nature of cross-chain transactions, a deposit might be initiated when the bridge is enabled, but rejected on withdrawal if the bridge is disabled in the meantime.

   3. The same logic can be applied to whitelist addresses, if the address is removed from whitelist there is no mechanisim to retransfer the tokens.

3. Lack of address validation:

   1. Neither L1 nor L2 sides implement restrictions on owner/recipient addresses.

   2. This could potentially allow transfers to invalid addresses (e.g., address(0)).

Impact

1. Auto-withdraw flag inconsistency:

   1. Users setting use_withdraw_auto to true on L2 will have their withdrawals fail on L1.

   2. This results in permanent loss of tokens, as they are burned on L2 but never minted on L1.

2. Asymmetric bridge enablement:

   1. Users may deposit tokens when the bridge is enabled, but be unable to withdraw if the bridge is disabled before their transaction is processed.

   2. This could lead to temporary or permanent loss of access to funds.

3. Lack of address validation:

   1. Potential for user error leading to loss of funds if tokens are sent to invalid or unintended addresses.

The overall impact is high, as these issues can lead to permanent loss of user funds with no recovery mechanism.

Tools Used

Manual code review

Recommendations

1. Auto-withdraw flag:

   1. Modify the L2 deposit_tokens() function to always set use_withdraw_auto = false.

   2. Alternatively, ensure the L1 side handles this flag consistently with L2.

2. Bridge enablement:

   1. Remove the "enabled" check from withdrawal functions on both L1 and L2.

   2. If disabling both deposit and withdraw is required, introduce a separate state variable for this purpose.

   3. Or implement a time-delay mechanism for disabling withdrawals to allow pending transactions to complete.

   4. Or encode the 'enabled' state in the deposit request and use it on the withdraw function on the other side of the bridge.

3. Address validation:

   1. Implement consistent address validation on both L1 and L2 sides.

   2. At minimum, prevent transfers to address(0) or other known invalid addresses.

4. General recommendations:

   1. Consider adding recovery mechanisms for trapped funds.