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

Missing Access control in `deploy_erc721_bridgeable()` function in `collection_manager.cairo` allows for the creation of various erc721bridgeable contracts associated with any arbitary l1 collection address

Summary

The deploy_erc721_bridgeable() function in collection_manager.cairo lacks proper access control, allowing unauthorized entities to deploy multiple ERC721 bridgeable contracts. This could lead to the deployment of numerous ERC721 bridgeable contracts associated with the same L1 NFT address, causing potential disruptions and malicious activities.

Vulnerability Details

Description

The deploy_erc721_bridgeable() function is currently exposed without any restrictions, meaning anyone can call this function to deploy an ERC721 bridgeable contract. The function accepts the following parameters:

  • class_hash: The class hash of the ERC721 contract to be deployed.

  • salt: A value used to influence the deployment address.

  • name: The descriptive name of the ERC721 collection.

  • symbol: The abbreviated name of the ERC721 collection.

  • base_uri: The base URI for the ERC721 metadata.

  • bridge_address: The address of the bridge contract.

Without access control, an attacker can provide arbitrary values for these parameters, especially the bridge_address parameter, which can be set to a legitimate L1 bridge address to make the contract seem legitimate. This opens up several attack vectors, such as deploying multiple ERC721 bridgeable contracts that appear to be associated with a legitimate L1 collection, which can confuse users and potentially lead to exploitation.
Vulnerable code

fn deploy_erc721_bridgeable(
class_hash: ClassHash,
salt: felt252,
name: ByteArray,
symbol: ByteArray,
base_uri: ByteArray,
bridge_address: ContractAddress,
) -> ContractAddress {
// @audit : no access control to execute this function (only the bridge should be able to deploy a new collection)
let mut calldata: Array<felt252> = array![];
name.serialize(ref calldata);
symbol.serialize(ref calldata);
base_uri.serialize(ref calldata);
calldata.append(bridge_address.into());
calldata.append(bridge_address.into());
match starknet::deploy_syscall(class_hash, salt, calldata.span(), false) {
Result::Ok((addr, _)) => addr,
Result::Err(revert_reason) => panic(revert_reason)
}
}

Exploitation Scenario

  1. Unauthorized Deployment: An attacker calls the deploy_erc721_bridgeable() function and provides a valid bridge_address from a well-known L1 bridge.

  2. Duplicate Contracts: The attacker can deploy multiple ERC721 bridgeable contracts under the guise of being legitimate collections, all pointing to the same L1 NFT address or bridge address.

  3. Malicious Intent: These unauthorized contracts could be designed to look and act similarly to legitimate ones, potentially tricking users into interacting with malicious contracts, leading to financial loss or data theft.

Example

Consider an L1 bridge address 0xABC...123 that is trusted by users. An attacker uses the deploy_erc721_bridgeable() function to deploy several ERC721 contracts that use this address. Users might believe these contracts are legitimate and interact with them, resulting in potential financial loss or other security issues.

Impact

Severity: High

  1. Make the Function Internal: Restrict the deploy_erc721_bridgeable() function to internal calls only, preventing external users from invoking it directly.

  2. Access Control with Role-Based Restrictions:

    • Use role-based access control (RBAC) to restrict this function to specific roles (e.g., only the bridge contract, contract owner, or admin should have the ability to deploy new ERC721 contracts).

Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.