Aave DIVA Wrapper

Summary

The _createContingentPool function allows pool creators to specify a dataProvider responsible for reporting the final value of the reference asset used to settle contingent pools. While DIVA Protocol is oracle-agnostic and offers flexibility, the lack of on-chain enforcement to verify or restrict dataProviders to trusted sources introduces a critical vulnerability. A malicious actor can specify themselves or an unreliable smart contract as the dataProvider, allowing them to manipulate the settlement process and rug users by reporting fraudulent values.

Vulnerability Details

• Unverified dataProvider:

• The _createContingentPool function accepts any Ethereum address (EOA or smart contract) as the dataProvider without validating whether it is part of a trusted whitelist. This opens the door for malicious actors to exploit this trust model and act as the oracle, providing manipulated reference values.

• Non-Guaranteed Fallback for Non-Whitelisted Providers:

  • The fallback mechanism guarantees intervention only for pools created with whitelisted dataProviders. For non-whitelisted providers, fallback intervention is discretionary and not mandatory, leaving such pools vulnerable to manipulation or unresolved settlements.

• Challenge Mechanism Abuse:

  • If the challenge mechanism is enabled, malicious dataProviders can repeatedly submit manipulated values, forcing token holders to engage in expensive and time-consuming challenges. This can lead to user fatigue or financial loss as users may accept an incorrect value to avoid further delays.

• Impact on Non-Expert Users:

  • The oracle-agnostic design assumes users will carefully vet the dataProvider before interacting with the pool. Non-expert users may unknowingly interact with pools backed by untrusted dataProviders, resulting in significant losses.

Exploitation Scenario

1. A malicious pool creator specifies themselves as the dataProvider.

2. Upon pool expiration, the malicious actor submits a manipulated reference value that maximizes their payout and minimizes the payouts for other users.

3. If users challenge the value, the malicious actor delays the settlement by repeatedly submitting fraudulent values, increasing users' gas costs and frustration.

4. For non-whitelisted pools, if the fallback provider does not intervene, users are left with unresolved or manipulated settlements.

Impact

This is a high-severity vulnerability because:

• It allows malicious actors to manipulate pool settlements, leading to user losses.

• Non-whitelisted pools are particularly vulnerable due to the discretionary nature of fallback intervention.

• Abuse of the challenge mechanism can result in prolonged delays and increased gas costs, eroding user trust and harming the protocol's reputation.

Tools Used

Recommendations

Enforce Whitelisting of Data Providers:

• Require all dataProviders to be part of a trusted on-chain whitelist before allowing pool creation.

• Example implementation:

Mandatory Fallback Mechanism:

• Update the fallback mechanism to guarantee intervention for all pools, regardless of whether the dataProvider is whitelisted or not.

• Restrict Challenge Mechanism Abuse:

  • Limit the number of times a dataProvider can resubmit values during a challenge. For instance:

1. Encourage Decentralized Oracles:

   • Require or incentivize the use of decentralized oracle solutions (e.g., Chainlink, Tellor) for high-value pools to ensure reliable and tamper-resistant reference values.

2. Improve User Awareness:

   • Clearly document the risks associated with untrusted dataProviders and encourage users to verify the trustworthiness of providers before interacting with a pool.