QuantAMM

Summary

The CalculateNewWeights function in the smart contract does not impose any explicit limit on the size of the _lambdaStore array, which is passed as input. This creates a vulnerability where a malicious actor can submit an excessively large array to:

1. Cause the function to exceed the Ethereum Virtual Machine (EVM) block gas limit, leading to a denial of service (DoS).

2. Gas grief legitimate users by significantly increasing gas costs, rendering the contract unaffordable or inefficient to use.

Vulnerability Details

Location:

The issue occurs in the CalculateNewWeights function, specifically in the handling of the _lambdaStore parameter:

Issue:

1. Unbounded Input Size:

   • _lambdaStore is accepted as a calldata array without any restriction on its length.

   • The function loops through every element in _lambdaStore to process and convert the values into int128. This loop’s execution cost scales linearly with the size of _lambdaStore.

2. Gas Costs:

   • If a malicious user submits a very large _lambdaStore array, the gas cost of processing this array will either:

     • Exceed the EVM block gas limit, causing the transaction to fail and resulting in a DoS.

     • Consume extremely high gas, making the function prohibitively expensive for subsequent legitimate users.

3. EVM Constraints:

   • While the EVM block gas limit restricts the maximum computational cost of a single transaction, an attacker could submit an array that is sufficiently large to:

     • Avoid an immediate revert.

     • Inflate gas costs to the extent that legitimate users are discouraged from interacting with the contract.

Impact

1. Denial of Service (DoS):

   • Transactions involving the CalculateNewWeights function may fail if the gas required exceeds the block gas limit, preventing legitimate operations.

2. Gas Griefing:

   • Even if the transaction does not exceed the block gas limit, processing large arrays significantly increases gas costs. This can deter legitimate users from interacting with the smart contract due to high transaction fees.

3. Operational Inefficiency:

   • Large arrays unnecessarily burden the network and hinder the contract's usability.

Examples:

Scenario 1: DoS by Exceeding Block Gas Limit:

An attacker submits a _lambdaStore array with 1,000,000 elements. The CalculateNewWeights function attempts to loop through and process each element:

• The loop execution cost exceeds the EVM block gas limit.

• The transaction fails, effectively causing a DoS for the function.

Scenario 2: Gas Griefing by Exploiting High Costs:

An attacker submits a _lambdaStore array with 10,000 elements:

• The transaction successfully executes but consumes excessive gas.

• The high gas cost discourages subsequent legitimate users from interacting with the contract, especially in competitive or resource-constrained environments.

Tools Used

Manual Review

Recommendations

• Enforce a Limit on _lambdaStore Length:

  • Introduce a require statement to restrict the size of _lambdaStore:

    + require(_lambdaStore.length <= MAX_LAMBDA_LENGTH, "Lambda store too large");

  • The MAX_LAMBDA_LENGTH value should reflect system requirements, such as the maximum number of assets in a pool.

• Align Length with Pool Tokens:

  • Enforce that the length of _lambdaStore matches the number of assets in the pool (_prevWeights.length):

    + require(_lambdaStore.length == _prevWeights.length, "Invalid lambda length");

• Gas-Efficient Processing:

  • Optimize the loop logic and avoid unnecessary operations to minimize gas consumption.

• Batch Processing (if necessary):

  • If large arrays are unavoidable, implement batch processing to divide the operation into smaller, more manageable steps.

• User Education and Monitoring:

  • Inform users of potential gas costs for submitting large arrays.

  • Monitor and log unusually large transactions to identify potential abuse