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

Potential front-running vulnerability in `initialize` function

Github

https://github.com/Cyfrin/2024-07-ark-project/blob/a1e10ca451f9e24d33b4418009eece666f14f15e/apps/blockchain/ethereum/src/Bridge.sol#L44-L66

Summary

The UUPSOwnableProxied contract includes an onlyInit modifier to ensure the initialize function is called only once. However, the initialize function in Bridge.sol can be front-run due to the deployment scripts not performing all actions in a single transaction. This allows any user to potentially manipulate the initialization process and claim administrative control over the contract.

Vulnerability Details

The Bridge involves deploying and initializing proxy contracts for bridging NFTs (ERC-721) between Ethereum (L1) and Starknet (L2). The key components include the bridge admin who manages the bridge settings and users who perform the bridging of NFTs.

Initialization Process:

  • The initialize function in Bridge.sol is protected by the onlyInit modifier from the UUPSOwnableProxied contract to ensure it is only called once.

  • This function sets critical parameters, including the owner, Starknet core address, and other necessary configurations.

Deployment Scripts:

  • The provided deployment scripts perform contract deployment and initialization in separate transactions.

  • This gap between deployment and initialization can be exploited by a malicious actor who can front-run the initialization transaction.

Impact

  • If a malicious actor front-runs the initialization process, they can call the initialize function and set themselves as the owner.

  • This would give them control over the contract, allowing them to manipulate the bridge settings, including enabling/disabling the bridge, setting mappings, and potentially stealing NFTs or funds.

Proof of Concept

  1. Alice, the legitimate bridge admin, deploys the ArkProject NFT Bridge contract using the provided scripts.

  2. The contract is deployed but not yet initialized.

  3. Bob, a malicious actor, monitors the blockchain for new contract deployments. Upon detecting the deployment of the Bridge contract, Bob quickly sends a transaction to call the initialize function.

  4. Bob's transaction gets mined before Alice's initialization transaction.

  5. Bob sets himself as the owner during the initialization process.

  6. With administrative control, Bob can disable the bridge, whitelist malicious contracts, and potentially steal any NFTs or funds bridged through the contract.

  7. Alice loses control over the bridge. Users bridging NFTs can have their assets stolen or manipulated.

Recommendations

To prevent this attack, the deployment and initialization process should be atomic, ensuring both actions occur within the same transaction. This can be achieved by updating the deployment scripts to perform both actions together.

Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

invalid-bridge-initialize-frontrun

If frontrun at the first deployment, protocol will deploy again, no real impact: informational. Moreover it is already deployed and initialize on mainnet. For the upgrades, `initialize` can/will change for the next update since the owner is already set. A lot of protocol make that change. That’s why I consider it like a future feature and it is out of scope.

Support

FAQs

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