QuantAMM

Summary

The QuantammMathMovingAverage::_calculateQuantAMMMovingAverage function does not impose any restrictions on the size of the _lambda and _newData arrays passed as parameters. This omission makes it possible for a malicious user to craft a transaction with excessively large arrays. Although these transactions might stay below the Ethereum Virtual Machine (EVM) block gas limit, they could result in high gas costs, rendering subsequent legitimate transactions economically infeasible. This vulnerability represents a Denial-of-Service (DoS) risk and could lead to inefficiencies in the system.

Vulnerability Details

• Both _newData and _lambda are dynamic arrays passed to the function.

• The function iterates through these arrays using a for loop, performing calculations for each element.

• There is no limit on the size of these arrays, allowing an attacker to input extremely large arrays just below the EVM’s block gas limit. This could:

  • Cause the transaction to consume excessive gas.

  • Lead to an economic DoS for subsequent legitimate users, as the gas usage increases significantly.

Impact

• Economic Denial-of-Service (DoS): Maliciously large array inputs can make contract interactions prohibitively expensive.

• System Inefficiency: Lack of input validation opens the door to misuse and inefficiencies during execution.

Example Scenarios

Malicious Scenario

1. Attacker passes arrays of size 10,000 to _newData and _lambda.

2. Gas usage for processing this large input significantly increases but remains below the block gas limit.

3. Legitimate users find subsequent transactions prohibitively expensive due to high base gas requirements caused by the attacker’s input.

Tools Used

Manuel Review

Recommendations

1. Limit Array Size Implement an upper limit on the size of _lambda and _newData. For example:

   function _calculateQuantAMMMovingAverage(

   int256[] memory _prevMovingAverage,

   int256[] memory _newData,

   int128[] memory _lambda,

   uint _numberOfAssets

   ) internal pure returns (int256[] memory) {

   + uint constant MAX_ARRAY_SIZE = 100; // Maximum number of assets supported

   + require(_newData.length <= MAX_ARRAY_SIZE, "Array size exceeds limit");

   + require(_lambda.length <= MAX_ARRAY_SIZE || _lambda.length == 1, "Invalid lambda array size");

   ​

   int256[] memory newMovingAverage = new int256[]();

   // Continue with the calculations...

   }

2. Estimate Gas Costs Before proceeding with execution, ensure the estimated gas costs do not exceed a safe threshold:

   + uint estimatedGas = gasleft();

   + require(estimatedGas > SAFE_MINIMUM_GAS, "Insufficient gas for operation");

3. Validate Array Consistency Ensure the sizes of _newData, _lambda, and _prevMovingAverage match _numberOfAssets:

   + require(_newData.length == _numberOfAssets, "Array size mismatch");

   + require(_lambda.length == _numberOfAssets || _lambda.length == 1, "Invalid lambda array size");

This vulnerability allows malicious actors to exploit the absence of input size validation, potentially leading to high gas costs and a Denial-of-Service (DoS) condition. By enforcing limits on the input size and validating array consistency, this issue can be mitigated effectively. This is a critical recommendation to enhance the robustness and security of the contract. Personally, I feel the third recommendation is best suited for the project.