DeFiFoundry
50,000 USDC
View results
Submission Details
Severity: low
Invalid

Missing Input Validation in `setMinMaxDepositAmount`

Details:
The setMinMaxDepositAmount function in the PerpetualVault contract allows the owner to configure the minimum and maximum deposit amounts. However, the function does not enforce any validation rules to ensure that the _minDepositAmount is less than _maxDepositAmount or that the minimum deposit is set to a safe threshold. This oversight can lead to configurations where deposits become impossible or unsafe, depending on how these parameters are set.

Root Cause:
Lack of input validation checks within the setMinMaxDepositAmount function. The function directly assigns the provided values without verifying:

  • That _minDepositAmount is lower than _maxDepositAmount.

  • That _minDepositAmount is not set to a value too low, which could open avenues for potential exploits.

Impact:

  • Operational Disruption: If _minDepositAmount is mistakenly set higher than _maxDepositAmount, it would block any deposit attempts, potentially halting vault operations.

  • Security Concerns: Setting the minimum deposit amount too low might expose the system to exploitation, as it could allow users to bypass intended economic constraints.

  • Human Error: Even though the function is owner-restricted, misconfiguration by the owner (or a compromised admin account) could lead to unintended and adverse system behavior.

Recommendation:

  • Enforce Order Constraint: Add a check to ensure that _minDepositAmount is strictly less than _maxDepositAmount.

    require(_minDepositAmount < _maxDepositAmount, "minDepositAmount must be less than maxDepositAmount");
  • Enforce Safe Thresholds: Optionally, enforce that _minDepositAmount meets a minimum value (e.g., 1000) and _maxDepositAmount does not exceed a maximum value (e.g., 100000) as per the README guidelines.

    require(_minDepositAmount >= 1000, "minDepositAmount too low");
    require(_maxDepositAmount <= 100000, "maxDepositAmount too high");
  • Documentation: Update the documentation to clearly state the acceptable range for deposit amounts to avoid misconfiguration.

Proof of Concept:

  1. The owner calls setMinMaxDepositAmount with the following parameters:

    • _minDepositAmount = 200000

    • _maxDepositAmount = 100000

  2. Since there is no validation, the contract accepts these values.

  3. As a result, any deposit operation requiring an amount between the minimum (200000) and maximum (100000) will fail, effectively preventing deposits and disrupting vault operations.

  4. Similarly, if _minDepositAmount is set to an extremely low value (e.g., 0), it might allow deposits that should be considered unsafe per the system’s economic design.

Implementing the recommended checks would mitigate these risks by ensuring that the deposit boundaries are logically consistent and within acceptable limits.

Updates

Lead Judging Commences

n0kto Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Admin is trusted / Malicious keepers

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."

n0kto Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Admin is trusted / Malicious keepers

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.