An adversarial attacker can initialize ListFactory

[code423n4]

Handle

hrkrshnn

Vulnerability details

An adversarial attacker can initialize ListFactory

The ListFactory contract has a default constructor. However, the proper initialization of state variables is done in initListFactor. This makes it vulnerable to front-running as well as a targeted attack by an adversary.

Here is an example flow of events:

1. Alice deploys ListFactory
2. Alice calls ListFactory.initListFactory(_accessControls, _pointListTemplate, _minimumFee).
3. Bob can watch the above tx in the mempool and frontrun it changing the values of _accessControls, _pointListTemplate and _minimumFee to whatever they please.
4. Alice's initListFactory reverts.

If Alice is not careful enough to check if their call succeeded, then they might use an incorrectly initialized ListFactory contract.

A second flow of events:

1. Alice deploys ListFactory
2. Bob watches the mempool for a create tx with bytecode that matches the bytecode of ListFactory (Bob has to plan this in advance).
3. Bob sends an ListFactory.initListFactory(_accessControls, _pointListTemplate, _minimumFee) to immediately follow Alice's ListFactory deployment. Tools such as flashbots allow doing this precisely.

Alice's deployed contract is now useless, since the parameters were initialized by Bob. Bob can effectively deny Alice from deploying a useful version of ListFactory.

Note that there are several other places, where this pattern is used, for example in MISOAccessFactory (generally, function names that match init* would all fall under this category.)

Recommended Mitigation Steps

• Consider doing the initialization in the constructor code itself. Implementing this is easy and quintessential. Doing it in the constructor also opens up for some gas optimization as well: for example, the state variable accessControls and pointListTemplate can be made immutable.
• Or, Deploy ListFactory from another smart contract using a create call, followed by initListFactory(...) in the same transaction.

If the latter approach is used, consider explicitly specifying this in the contract documentation.

[ghoul-sol]

To my understanding ListFactory is part of original deployment so I guess that developers would see misconfigured system before releasing it to production. Also, front running deployments is quite rare with an exception of Curve DAO of course. Low risk.