QuantAMM

Summary:

The QuantAMMWeightedPoolFactory allows users to provide a salt parameter when creating a new pool. An attacker can exploit this by frontrunning a user's pool creation transaction and deploying a contract at the address where the user's pool would be deployed (by using the same salt and deployment parameters). This causes the user's deployment to fail due to an address collision, effectively blocking them from deploying their pool. Repeatedly performing this attack can result in a Denial of Service (DoS) against the user.

Root Cause:

When deploying a contract using CREATE2, the address where the contract will be deployed is determined by the deploying address (in this case, the factory's address), the salt provided, and the contract's bytecode.

In the create function in QuantAMMWeightedPoolFactory, users provide a salt:

An attacker can monitor the network for pending transactions that call create and extract the salt and deployment parameters. By frontrunning the user's transaction and providing the same salt and pool parameters, the attacker can deploy a contract at the address where the user's pool would have been deployed.

Since CREATE2 will fail if there is already a contract at the computed address, the user's deployment will fail, causing a Denial of Service.

Attack Path:

1. User Initiates Pool Deployment:

   • A user calls the create function with their desired parameters, including a salt of their choice.

2. Attacker Observes Pending Transaction:

   • The attacker monitors the mempool and identifies the user's pending create transaction.

   • They extract the salt and the parameters used for deployment.

3. Attacker Frontruns the Deployment:

   • The attacker crafts a transaction that calls the create function with the same salt and parameters.

   • The attacker pays a higher gas price to ensure their transaction is mined before the user's transaction.

4. Attacker Deploys a Dummy Contract or Malicious Pool:

   • The attacker deploys a contract to the address where the user's pool would have been deployed.

   • This could be a dummy contract or a malicious pool.

5. User's Deployment Fails:

   • When the user's transaction is mined, the CREATE2 deployment fails because the contract address is already in use.

   • The user's transaction reverts, and they cannot deploy their pool.

6. Denial of Service:

   • If the attacker repeats this process, they can continually prevent the user from deploying their pool.

Proof of Concept (PoC):

1. User's Transaction:

   • The user calls the factory's create function:

     // User's parameters

     bytes32 userSalt = 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef;

     NewPoolParams memory userParams = NewPoolParams({

     // ... user's pool parameters ...

     salt: userSalt,

     // ...

     });

     ​

     // User calls create

     quantAMMWeightedPoolFactory.create(userParams);

2. Attacker's Frontrunning Transaction:

   • The attacker observes the user's pending transaction and extracts userSalt and userParams.

   • The attacker calls create with the same salt and parameters:

     // Attacker uses the same salt and parameters

     quantAMMWeightedPoolFactory.create(userParams);

   • The attacker pays a higher gas price to ensure their transaction is mined first.

3. Outcome:

   • The attacker's deployment succeeds, and the contract is deployed at the intended address.

   • The user's deployment fails due to the address collision.

Impact:

• Denial of Service: The attacker can prevent the user from deploying their pool by ensuring that the address is already in use.

• Potential Repetition: The attacker can repeat this process indefinitely, continually blocking the user's deployment attempts.

• User Frustration and Loss of Time: Users may be unable to launch their pools, causing delays and potential financial impact.

Recommendation:

To prevent this Denial of Service attack, the factory should not rely on user-provided salts for the CREATE2 deployment. Instead, the factory can generate the salt internally, ensuring it is unique and unpredictable for each pool deployment.

Modified Code:

Remove the salt parameter from user input and generate it within the factory: