Summary

The AaveDIVAWrapperCore contract allows users to create contingent pools via the _createContingentPool function. However, inadequate validation of the provided PoolParams introduces risks of protocol misconfiguration, economic exploitation, and financial instability. Attackers can exploit this flaw to manipulate pools, causing instant liquidation, unauthorized claims, or locked collateral, undermining the protocol’s economic integrity and user trust.

Root Cause

The _createContingentPool function lacks sufficient validation for critical pool parameters such as:

• Expiry Dates: Pools can be created with expiry dates set in the past or excessively far in the future.

• Strike Prices: Strike prices can be set to economically unrealistic values, creating arbitrage opportunities.

• Collateral Ratios: Collateral ratios can be configured too low (causing immediate liquidation) or too high (locking excess collateral).

Code Reference:

• No Checks on Expiry Time: expiryTime is not validated to ensure it is in the future or within a reasonable range.

• No Checks on Strike Prices or Collateral Ratios: Parameters like inflection, cap, and gradient are not validated for economic realism.

Attack Scenarios

Exploiting Past Expiry Dates for Unauthorized Claims

• An attacker creates a pool with an expiry date set to the current block or a past block.

• The pool is created in an expired state, allowing the attacker to immediately resolve the pool and claim unauthorized funds.

3. Impact:

   • Unauthorized Claims: The attacker drains the pool’s collateral without actual economic activity.

   • Protocol Financial Losses: Legitimate users lose their funds to attackers exploiting misconfigured pools.

Arbitrage with Unrealistic Strike Prices

• The attacker creates a pool with an unreasonably low strike price relative to the market price of the underlying asset.

• The attacker manipulates the pool resolution process, creating a scenario where the payout heavily favors their position.

3. Impact:

   • Economic Exploitation: The attacker generates arbitrage profits at the expense of other users.

   • Protocol Instability: Manipulated pools disrupt market equilibrium within the protocol.

Locked Collateral Due to Extreme Collateral Ratios

• A legitimate user creates a pool with an excessively high collateral ratio.

• The pool locks collateral unnecessarily, preventing liquidity providers from efficiently utilizing their funds.

3. Impact:

   • User Frustration: Collateral remains inaccessible for long periods.

   • Liquidity Drain: Protocol liquidity is artificially constrained, reducing efficiency.

Impact

Severity: High

1. Unauthorized Fund Claims:

   • Attackers can drain collateral by exploiting expired or misconfigured pools.

2. Economic Manipulation:

   • Arbitrary strike prices enable attackers to profit at the expense of the protocol and legitimate users.

3. Protocol Instability:

   • Misconfigured pools disrupt liquidity and reduce trust in the protocol.

Recommendations

1. Comprehensive Validation of Pool Parameters

Implement strict validation for all critical parameters:

• Expiry Dates: Ensure the expiry date is in the future and within a reasonable range:

  require(_poolParams.expiryTime > block.timestamp, "Expiry date must be in the future");

  require(_poolParams.expiryTime <= block.timestamp + MAX_EXPIRY_DURATION, "Expiry date too far in the future");

  ​

• Strike Prices: Validate strike prices relative to the market price of the underlying asset:

  uint256 currentPrice = priceOracle.getPrice(_poolParams.referenceAsset);

  require(_poolParams.strikePrice > MIN_STRIKE_PRICE, "Strike price too low");

  require(_poolParams.strikePrice <= currentPrice * MAX_STRIKE_MULTIPLIER, "Strike price too high");

  ​

• Collateral Ratios: Enforce reasonable collateral ratios to prevent excessive locking or insufficient coverage:

  require(_poolParams.collateralAmount >= MIN_COLLATERAL_RATIO, "Collateral ratio too low");

  require(_poolParams.collateralAmount <= MAX_COLLATERAL_RATIO, "Collateral ratio too high");

  ​

2. Leverage Oracles for Dynamic Validation

Integrate price oracles to fetch real-time data and dynamically validate parameters like strike prices and collateral ratios:

3. Sanity Checks for Additional Parameters

Validate other essential fields such as referenceAsset and poolSize:

• require(_poolParams.referenceAsset != address(0), "Invalid reference asset");

  require(_poolParams.poolSize > 0, "Pool size must be greater than zero");

  ​

4. Introduce a Pool Creation Cap

Restrict the number of pools a single user can create within a specific timeframe to mitigate abuse:

Proof of Concept (PoC)

Malicious Pool Creation

• Deploy the contract and create a pool with the following parameters:

  • Expiry date: block.timestamp - 1 (past block).

  • Collateral ratio: 0.1 (insufficient coverage).

2. Exec:

   • Call _createContingentPool with the manipulated parameters.

   • Observe that the pool is created successfully despite being misconfigured.

3. Impact:

   • Immediate exploitation of expired pool for unauthorized claims.

   • Locked collateral due to invalid configurations.