Aave DIVA Wrapper

Summary

The AaveDIVAWrapperCore contract serves as the foundational component of the protocol, providing the essential structure upon which the AaveDIVAWrapper contract builds. The latter extends AaveDIVAWrapperCore to create a fully functional implementation of the protocol.

As an abstract contract, AaveDIVAWrapperCore includes a constructor that is invoked in a manner similar to the AaveDIVAWrapper contract. However, the AaveDIVAWrapperCore contract does not define its constructor parameters directly; instead, it receives them from its descendant, AaveDIVAWrapper. Specifically, the constructor of AaveDIVAWrapperCore expects the following arguments:

• address diva_: The address of the DIVA Protocol contract.

• address aaveV3Pool_: The address of the Aave V3 lending pool contract.

• address owner_: The owner’s address, which is further passed to the OpenZeppelin Ownable contract to establish ownership control.

To prevent unintended initialization, the constructor enforces a strict validation mechanism, ensuring that none of the provided addresses (except owner_, which is validated within OpenZeppelin's Ownable contract) are zero addresses. If an invalid address is provided, the contract execution is halted by triggering a ZeroAddress() revert.

AaveDIVAWrapperCore Constructor Implementation - Reference Link

By maintaining a well-structured and modular design, the AaveDIVAWrapperCore contract ensures that the AaveDIVAWrapper contract can efficiently interact with both DIVA Protocol and Aave V3 while adhering to security best practices.

Vulnerability Details

Despite the well-structured inheritance model, a critical flaw exists in the way the AaveDIVAWrapper contract passes constructor arguments to AaveDIVAWrapperCore. Instead of supplying the parameters in the correct order (diva_, aaveV3Pool_, owner_), the AaveDIVAWrapper constructor mistakenly provides them in the following incorrect sequence:

1. _aaveV3Pool (Aave V3 Pool address)

2. _diva (DIVA Protocol address)

3. _owner (Owner's address)

This incorrect argument order fundamentally breaks the intended functionality of the protocol. When AaveDIVAWrapperCore attempts to assign the received values, it mistakenly interprets _aaveV3Pool as diva_, _diva as aaveV3Pool_, and _owner as owner_. As a result, the contract operates with incorrectly assigned addresses, leading to a complete breakdown of the protocol.

AaveDIVAWrapper Constructor with Incorrect Argument Order - Reference Link

This oversight results in a Denial of Service (DoS) scenario that renders the entire Aave Diva Wrapper Protocol completely dysfunctional. Since the contract relies on valid addresses to execute key functions, the incorrect assignments cause every interaction to fail. The repercussions of this issue impact all participants in the ecosystem:

• Users: Unable to create liquidity pools, add or remove liquidity, redeem position tokens, or convert wrapped collateral tokens back to the original token.

• Owner: Incapable of registering new collateral tokens or claiming yield generated from Aave deposits.

• Data Providers / Oracles: Unable to resolve pools by reporting outcomes to the DIVA Protocol.

Proof of Concept

To demonstrate this vulnerability, a Proof of Concept (PoC) is provided below.

Note: The PoC is written using the Foundry tool.

1. Step 1: Make a foundry project and put all the contracts in the src directory.

2. Step 2: Create a test folder and mocks folder in the test and src directories respectively (or we already have a mocks folder in src).

3. Step 3: Create all necessary mocks

4. step 4: Create a test file with any name in the test directory.

1. Step 5: Now, Put the following Test PoC in the test file adjacent to the setUp function.

1. Step 6: Now, to run the test, run the following commands in the terminal in sequence:

1. Step 7: See the output of the test in the terminal, the output should be similar to the below one:

As demonstrated in the output, test passes and there're so many reverts, these reverts proved that wrong order of parameters cause a severe DoS.

Impact

The incorrect ordering of constructor parameters in the AaveDIVAWrapper contract has severe consequences that ripple across the entire Aave Diva Wrapper Protocol, leading to complete inoperability.

1. Complete Dysfunctionality of the Protocol

The misordered parameters cause AaveDIVAWrapperCore to store incorrect addresses for DIVA Protocol, Aave V3 Pool, and Owner. Since these addresses are fundamental to the contract’s ability to interact with external protocols and manage ownership, their misconfiguration renders the protocol non-functional.

• Calls to DIVA Protocol functions fail because the contract is referencing an incorrect address instead of the actual DIVA contract.

• Attempts to interact with the Aave V3 Pool fail due to the contract pointing to an invalid address.

As a result, the entire protocol is frozen, with no actor being able to perform any intended operations.

2. Denial of Service (DoS) for All Participants

The misconfiguration results in a Denial of Service (DoS) across all major functionalities of the protocol. This affects every participant, as outlined below:

• Users (Liquidity Providers and Traders)

  • Unable to create pools or add liquidity, preventing them from earning yield.

  • Cannot redeem position tokens (both long and short) for their underlying collateral.

  • Cannot unwrap their collateral tokens back into the original asset, causing potential financial losses.

  • All interactions with the protocol revert due to incorrect contract references.

• Protocol Owner / Administrators

  • Cannot register collateral tokens, preventing the expansion of supported assets.

  • Unable to claim yield generated from Aave deposits, potentially leading to locked funds in the protocol.

• Data Providers and Oracles

  • Price settlement operations fail, as the protocol cannot correctly interact with the DIVA Protocol.

  • No pool resolutions can be processed, meaning no position tokens can be settled based on real-world events.

As a result, no participant can successfully use the protocol in any capacity.

3. The Necessity of Redeployment and Migration

Since the constructor is executed only once during contract deployment, this issue cannot be patched via an upgrade. The only way to resolve the problem is by redeploying a corrected version of the AaveDIVAWrapper contract with the correct parameter order.

This introduces additional challenges:

• All existing user funds and liquidity pools must be migrated to the new contract, requiring users to take action.

• Any previously issued position tokens will likely become invalid, requiring new tokens to be minted.

• Time and gas costs for developers, users, and liquidity providers increase, leading to inefficiencies.

If the protocol is not swiftly redeployed with a clear migration plan, the ecosystem may suffer long-term damage due to user frustration and loss of confidence.

• Why This Issue Should Be Considered Critical

  • The incorrect constructor parameter ordering in AaveDIVAWrapper is not a minor oversight. It is a critical vulnerability that completely disrupts the protocol’s functionality and can have severe financial, operational, and reputational consequences.

Tools Used

• Manual Review

• Foundry

Recommendations

To address the critical flaw caused by the incorrect ordering of constructor parameters in the AaveDIVAWrapper contract it is suggested that, Please correct the Constructor Parameter Order and Redeploy the Aave Diva Wrapper Protocol if this version is already deployed and already in production.

1. One Possible solution:

AaveDIVAWrapper::constructor:

1. As we know there could have so many solutions of a problem, so another one is also given below:

AaveDIVAWrapperCore::constructor:

Two solutions are provided, Please use either of one.