Aave DIVA Wrapper

Summary

The AaveDIVAWrapperCore contract exhibits a vulnerability in its token allowance management, particularly when interacting with tokens like USDT that decrement allowance with each transferFrom operation. The system relies on manual intervention to reset allowances, which can lead to failed deposits if not addressed in time.

Vulnerability Details

1. Infinite Allowance:

   • The contract sets an infinite allowance for collateral tokens with the following line of code:

     116: _collateralTokenContract.approve(_aaveV3Pool, type(uint256).max);

   • For tokens like USDT that reduce allowance on every transferFrom, this can lead to allowance depletion over time, causing future deposits to fail.

2. Manual Fallback Mechanism:

   • The approveCollateralTokenForAave function is provided as a fallback to manually reset the allowance:

     358: function _approveCollateralTokenForAave(address _collateralToken) internal {

     uint256 currentAllowance = IERC20Metadata(_collateralToken).allowance(address(this), _aaveV3Pool);

     IERC20Metadata(_collateralToken).safeIncreaseAllowance(

     _aaveV3Pool,

     type(uint256).max - currentAllowance

     );

     367: }

   • However, this function must be explicitly called by an external or system actor. If not triggered, the system will encounter deposit failures.

3. Acknowledgment of Token Behavior:

   • The contract acknowledges that certain tokens, like USDT, decrement allowance, but no automatic mechanism is implemented to mitigate this behavior:

     112: // this behavior may differ for collateral tokens like USDC, DAI, or WETH used in Aave. These tokens decrement the allowance with each use of `transferFrom`, even if an unlimited allowance is set.

Impact

1. User Experience:

   • Deposits can unexpectedly fail when the allowance is exhausted and the fallback function has not been triggered in time.

   • This affects user trust, particularly for high-value or frequent deposits.

2. Operational Overhead:

   • Reliance on manual intervention or system administrator action adds inefficiencies and increases the risk of errors.

3. Protocol Downtime:

   • If the allowance is depleted without timely re-approval, the system risks downtime or transaction reverts, potentially affecting a wide range of users.

Tools Used

• Manual code review of the AaveDIVAWrapperCore contract.

• Identification of patterns in allowance handling and fallback mechanisms.

• Analysis of token behavior (e.g., USDT) for compatibility with infinite allowance.

Recommendations

1. Automatic Allowance Replenishment:

   • Implement logic to dynamically reset allowance when it falls below a certain threshold during deposit operations:

     function ensureAllowance(address collateralToken) internal {

     uint256 currentAllowance = IERC20Metadata(collateralToken).allowance(address(this), aaveV3Pool);

     if (currentAllowance < MINIMUM_THRESHOLD) {

     IERC20Metadata(collateralToken).approve(aaveV3Pool, type(uint256).max);

     }

     }

2. Per-Transaction Allowance:

   • Replace infinite allowances with per-transaction approvals to avoid issues with decrementing allowances:

     IERC20Metadata(collateralToken).approve(aaveV3Pool, amountToDeposit);

3. Periodic Allowance Monitoring:

   • Use automation (e.g., Chainlink Keepers) to periodically check and reset allowances for tokens with decrementing behavior.

4. Token-Specific Handling:

   • Detect and handle tokens like USDT that decrement allowance differently from those that do not.

     if (isAllowanceDecrementingToken(collateralToken)) {

     IERC20Metadata(collateralToken).approve(aaveV3Pool, type(uint256).max);

     }