Aave DIVA Wrapper

Summary

The function createContingentPool in contract IDIVA.sol accepts many parameters, but there is no validation for certain critical values, such as floor, inflection, cap, capacity, and expiryTime. These inputs could be manipulated to create pools with malicious parameters, potentially leading to financial loss or misbehavior.

Vulnerability Details

• Unvalidated Inputs: The lack of checks on values like capacity could lead to excessive collateral being deposited into a pool, which might overflow or cause protocol malfunctions.

• Expiry Time: If the expiryTime is set incorrectly (e.g., in the past), it could lead to pools becoming invalid or impossible to redeem position tokens from.

Impact

Invalid pool configurations could result in financial loss, user funds being locked, or exploit opportunities for attackers.

PoC for Insufficient Validation for createContingentPool Inputs

Overview

The createContingentPool function in the IDIVA interface allows the creation of a pool by providing various parameters, including the collateral amount, reference asset, capacity, and recipients for the long and short tokens. Insufficient validation or improper checks on these inputs could lead to potential attacks, such as creating pools with invalid or malicious parameters that exploit the system or cause unintended behaviors.

Actors

• Attacker: The malicious user trying to exploit the pool creation mechanism.

• Victim: The protocol and its users who interact with the faulty pools.

• Protocol: The smart contract managing the pool creation and interaction.

Working Test Case

This PoC demonstrates a situation where the attacker can manipulate inputs to create a pool with invalid or dangerous parameters.

Step-by-Step Exploit Scenario

1. Attacker Prepares Malicious Parameters:

   • The attacker creates a PoolParams struct with invalid or manipulative parameters, including:

     • Invalid addresses (e.g., zero addresses for the collateral token, data provider, and recipients).

     • A gradient value exceeding valid bounds (2000 instead of a value between 0 and 1).

     • A reference asset that does not exist.

     • Expiry time set to the current timestamp (making it a past time).

     • The floor and inflection values being illogical or mismatched.

2. Attack Execution:

   • The attacker calls createContingentPool with the manipulated parameters in an attempt to create a pool with these unsafe values.

3. Expected Outcome:

   • The transaction is expected to fail due to the lack of validation checks in the createContingentPool function.

   • However, if the contract does not have adequate checks, the pool may be created with invalid parameters, leading to potential issues such as:

     • Pool interactions that do not function properly.

     • Potential loss of funds due to invalid capacity or collateral handling.

     • Malicious users being able to interact with a faulty pool and exploit the system.

4. Protocol Impact:

   • If insufficient validation is present and the pool is created, it can result in a pool that cannot be used properly or malicious users manipulating the contract for their benefit.

   • This could lead to incorrect payouts, loss of funds, or other operational failures in the protocol.

Tools Used

Manual code review

Recommendations & Fixes

1. Input Validation: Add proper validation for each parameter in the createContingentPool function:

   • Ensure that the collateralToken, dataProvider, longRecipient, and shortRecipient addresses are non-zero.

   • Validate the gradient to ensure it is between 0 and 1.

   • Check the floor, inflection, and cap values to ensure they are within logical bounds and do not conflict with each other (e.g., floor < inflection < cap).

   • Validate the expiryTime to ensure it is a future timestamp.

   • Ensure that the capacity is within a reasonable limit and the collateral amount does not exceed it.

2. Revert on Invalid Inputs: Ensure that the function reverts if any parameter fails validation, preventing the creation of faulty pools.

3. Unit Tests: Implement unit tests to ensure that the validation checks are working properly and that any attempt to create a pool with invalid parameters results in a failure.

By enforcing these validation checks, the contract can ensure that only valid pools are created, protecting the protocol and users from potential exploits or failures.