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.
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.
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.
Alice, the legitimate bridge admin, deploys the ArkProject NFT Bridge contract using the provided scripts.
The contract is deployed but not yet initialized.
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.
Bob's transaction gets mined before Alice's initialization transaction.
Bob sets himself as the owner during the initialization process.
With administrative control, Bob can disable the bridge, whitelist malicious contracts, and potentially steal any NFTs or funds bridged through the contract.
Alice loses control over the bridge. Users bridging NFTs can have their assets stolen or manipulated.
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.
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.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.