Frontrunning of some initializers to grief deployment possible

[code423n4]

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/24bc4d8dfeb6e4328d2c6291d20553b1d3eff00b/src/HolographBridge.sol#L63
https://github.com/code-423n4/2022-10-holograph/blob/24bc4d8dfeb6e4328d2c6291d20553b1d3eff00b/src/HolographFactory.sol#L44
https://github.com/code-423n4/2022-10-holograph/blob/24bc4d8dfeb6e4328d2c6291d20553b1d3eff00b/src/HolographOperator.sol#L141

Vulnerability details

Impact

The initializer function (init) is callable by anyone, not only the deployer of the contracts. For some contracts that are deployed by a factory (e.g., Holographer), this is not problematic because the factory will immediately initialize after deployment (in the same transaction), meaning no frontrunning is possible. However, some contracts (like the factory itself) are not deployed with a smart contract. For these, someone can frontrun the init call. In the worst case, when this is not detected, a deployment with wrong parameters (e.g., a different admin) is used. But even if it is detected, an attacker could continously front-run the call to make all deployments unusable.

Proof Of Concept

The HolographFactory contract is deployed and an attacker frontruns the init call. Because this deployment becomes useless, it is deployed again and the call is frontrun again, and again, and again...

Recommended Mitigation Steps

Store the deployer (temporarily), only let this address initiate the contracts.

[alexanderattar]

The Genesis contract deploys so this cannot be frontrun.