Aave DIVA Wrapper

Summary

The contract AaveDIVAWrapperCore.sol performs mathematical operations (e.g., in _redeemWTokenPrivate, _redeemPositionToken) without ensuring safe handling of overflows or underflows.

Vulnerability Details

The contract directly performs operations on values like token balances without using SafeMath. Although Solidity 0.8+ does have built-in overflow/underflow protection, relying on this alone could still cause issues in edge cases or unanticipated scenarios. It’s always best practice to use SafeMath for clarity and to avoid potential issues when interacting with other contracts.

Impact

While Solidity 0.8+ does provide overflow protection by default, it’s a good security practice to explicitly ensure safe arithmetic operations, especially when working with tokens or interacting with external protocols. Without this, an attacker may exploit the system through unexpected edge cases.

PoC for Lack of Safe Math Operations

Overview:

In the contract, there are several instances where basic arithmetic operations are performed on user-supplied data, but these operations do not use any safe math library (e.g., OpenZeppelin's SafeMath). This exposes the contract to the risk of overflow or underflow, which could result in incorrect contract behavior or even vulnerabilities that can be exploited by malicious actors.

Actors:

• Attacker: A user or attacker who can send manipulated values to trigger an overflow/underflow during arithmetic operations.

• Victim: The contract itself or users interacting with the contract, particularly the ones using affected functions.

• Protocol: The AaveDIVAWrapper contract, where critical financial operations such as transfers, balances, and positions are managed.

Working Test Case:

Line-by-line Comments:

• The test case starts by importing necessary libraries like ethers and chai for Hardhat's testing environment.

• beforeEach sets up the contract and initializes an ERC20 token for testing.

• The test checks for integer overflow and underflow by attempting to perform unsafe math operations. If these operations happen, they should revert with an error message like "SafeMath: addition overflow" or "SafeMath: subtraction underflow".

• A valid test case is included to check that math operations work correctly without overflow or underflow.

Exploit Scenario:

1. Initial State: The attacker has no tokens, and the contract is deployed with an unprotected math operation.

2. Step 1: The attacker tries to perform a calculation that leads to an overflow (e.g., adding 1 to MAX_UINT).

3. Step 2: The transaction should revert with a "SafeMath: addition overflow" error.

4. Step 3: The attacker tries to perform a calculation that leads to an underflow (e.g., subtracting 1 from 0).

5. Step 4: The transaction should revert with a "SafeMath: subtraction underflow" error.

6. Outcome: The contract will revert on any unsafe operation, ensuring that funds are not at risk due to math issues.

7. Implications: If the contract doesn't use safe math, attackers could exploit overflow/underflow vulnerabilities, leading to incorrect contract behavior, which could result in financial loss.

Recommended Mitigation:

• Use SafeMath library (from OpenZeppelin) for all arithmetic operations involving user-supplied values to prevent overflow/underflow issues.

• Modern versions of Solidity (0.8 and higher) include built-in overflow and underflow protection, so upgrading to a newer Solidity version is also an option if the contract is written in an older version.

Tools Used

Manual code review

Recommendations

Ensure that SafeMath (or equivalent checks) is used for all arithmetic operations to prevent overflow and underflow attacks.