Part 2

Summary

The initiateSwap function accepts three array parameters (vaultIds, amountsIn, and minAmountsOut) without imposing a maximum size limit. While the function checks that all arrays have matching lengths, it does not restrict the number of swap requests that can be submitted in a single transaction. This opens the door to potential Denial of Service (DoS) attacks where a malicious user could supply a massive batch of swaps, leading to excessive gas consumption and possibly exceeding block gas limits.

Vulnerability Details

The function is defined as:

##POC

Impact

• Denial of Service (DoS): An attacker can force the transaction to consume an excessive amount of gas by supplying very large arrays, causing the transaction to exceed the block gas limit.

• Resource Exhaustion: The excessive gas consumption and numerous storage operations could lead to network congestion or degraded performance for legitimate users.

• Blocked Operations: Legitimate swap operations could be prevented from execution if the network state is overwhelmed by such resource-intensive transactions.

Tools Used

• Manual Code Review: Careful inspection of the array input validations.

• Static Analysis Tools: Tools such as Slither and MythX helped identify the lack of an upper limit.

• Fuzz Testing: Frameworks like Forge Fuzz Testing simulated inputs with large array sizes to assess gas consumption.

Recommendations

• Introduce an Upper Bound: Enforce a maximum allowed length for the input arrays. For example, add a check such as:

  if (vaultIds.length > MAX_BATCH_SIZE) {

  revert Errors.ArrayLengthExceedsLimit(vaultIds.length, MAX_BATCH_SIZE);

  }

• Batch Processing: Consider splitting the processing into smaller batches if large numbers of swaps need to be supported.

• Gas Profiling: Regularly profile the gas consumption for this function and adjust the limits accordingly.

• Input Validation: Add input validation to reject unusually large arrays at the contract level before commencing any processing.