OlaHamid - Denial of Service (DOS) and Out of Gas (OOG) Vulnerability in matchOffersV3 Function

[sherlock-admin2]

OlaHamid

High

Denial of Service (DOS) and Out of Gas (OOG) Vulnerability in matchOffersV3 Function

SUMMARY

The matchOffersV3 function in the contract has potential vulnerabilities that can lead to Denial of Service (DOS) or Out of Gas (OOG) errors under certain conditions. These vulnerabilities can be exploited due to the way gas-heavy loops and external calls are handled, and they can also result in the freezing or blocking of specific loan operations. Additionally, malicious actors can exploit the reliance on certain parameters such as length checks, conditional oracle calls, and unoptimized loops.

ROOT CAUSE

https://github.com/sherlock-audit/2024-11-debita-finance-v3/blob/main/Debita-V3-Contracts/contracts/DebitaV3Aggregator.sol#L274

1. Gas-heavy Loops: The function performs multiple loops (for loops) over lendOrders and principles, which may result in high gas consumption when the inputs are large (e.g., when there are many lend orders or principles). This could lead to Out of Gas errors, particularly in cases of large input data.

2. Dependence on External Contracts: Multiple external contract calls (such as to DBOImplementation, DLOFactory, SafeERC20, etc.) occur inside loops without gas optimization. If any external call reverts or fails to respond in a timely manner, it may halt the execution of the function or exhaust gas.

3. Dynamic Data Processing: There is significant dynamic data processing and updates (e.g., weighted ratios, APRs, etc.) that might not be gas-efficient, especially when dealing with larger arrays.

4. Lack of Gas Limit Handling: The function doesn’t explicitly manage or handle gas limits, which could result in hitting the block gas limit when there are many lendOrders or principles.

Internal Precondition:

• The contract must be able to interact with the DBOFactory and DLOFactory contracts.
• Sufficient funds must be available for lending and borrowing operations.
• The contract must be in an unpaused state to accept new loans.

External Precondition:

• The borrowOrder and lendOrders must be legitimate as per the checks in the contract.
• The borrower's collateral and loan terms should be valid and match the expected criteria.
• The borrower's and lender's assets must be transferred successfully to the contract.

ATTACK PATH

1. DOS via Overloading Loops:

   • An attacker can trigger the function with a large number of lendOrders or principles that results in an expensive loop operation, potentially causing an Out of Gas (OOG) error.
   • The high gas consumption for each iteration of the loop (e.g., due to complex calculations and external calls) could exhaust the gas limit for the block.

2. Exploiting External Call Delays:

   • If any external contract (e.g., oracle or lending/borrowing contract) is delayed or fails, the transaction might fail, causing the operation to revert, preventing the successful matching of offers.
   • The reliance on oracles and external contracts introduces potential points of failure that can be exploited by malicious actors to halt operations.

3. Exploiting the Lack of Transaction Gas Limits:

   • The function’s reliance on dynamic data updates and loops without explicitly managing the gas cost or transaction limits may lead to unpredictable behavior, especially when large sets of data are involved.

POC (Proof of Concept):

• DOS Attack:

  1. Create a large number of lendOrders (e.g., 100) with complex data and pass them to the matchOffersV3 function.
  2. Monitor the gas consumption to see if the function exceeds the block's gas limit and fails with an Out of Gas error.

• Exploiting External Calls:

  1. Modify the DBOImplementation contract to simulate a delayed or failed oracle response.
  2. Call the matchOffersV3 function and observe if it reverts or fails during the execution of the external calls.

MITIGATION

1. Gas Optimization:

   • Implement batch processing or pagination for large datasets (e.g., lending offers, principles). This can break down the loops into smaller transactions and avoid excessive gas consumption in a single transaction.
   • Consider using view or pure functions for any computations that do not require state changes to avoid extra gas costs.
   • Avoid unnecessary state modifications or storage writes in loops; these operations are costly in terms of gas.

2. Gas Limit Management:

   • Introduce explicit gas limits or warnings for users to avoid excessive gas consumption.
   • Use gasleft() to monitor available gas and potentially revert if it is too low to continue processing.
   • Ensure that critical contract functions like lending/borrowing do not consume more gas than is acceptable.

3. Fallback and Timeout Mechanisms:

   • Implement fallback mechanisms for oracle calls or external contract interactions to handle delays or failures gracefully.
   • Introduce a timeout or retry mechanism in case of oracle failures to ensure that the transaction does not hang indefinitely.

4. Pre-validation:

   • Before invoking complex loops or external calls, validate that the data (e.g., number of lend orders, principles) is within a manageable range to prevent excessive computation.

5. Limitations on Lending:

   • Introduce checks to prevent too many lend orders or principles from being processed in a single transaction. This could involve setting limits or flags for large operations.

---

.