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

Missing initializer access control

Summary

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

Missing initializer access control resulting in costly new redeploy and protocol set-up interruption.

Vulnerability Details

In Bridge::initialize there is not access control and upon contract deployment an attack can call the function and initialize it with arbitrary data which will require a new redeploy of the contract. Even after a new redeploy the attacker may call the function again and again preventing the deployer from being able to initialize the configurations.

Overall, this will may cost additional gas cost due to each new redeployment and interruption of protocol set-up.

Impact

Impact: High

Likelihood: Low

Attacker calls Bridge::initialize before owner which requires costly new redeploy.

Proof of Concept

  1. Contract Bridge.sol is deployed.

  2. Attacker immediately calls Bridge::initialize with arbirary data.

Tools Used

Manual Review

Recommendations

Add onlyOwner access control in Bridge::initialize:

function initialize(
bytes calldata data
)
public
onlyInit
++ onlyOwner
{
...
}
Updates

Lead Judging Commences

n0kto Lead Judge 10 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.