Skip to content

Latest commit

 

History

History
82 lines (58 loc) · 3.89 KB

059.md

File metadata and controls

82 lines (58 loc) · 3.89 KB

Glamorous Plum Baboon

High

Unchecked Address Validations in Critical Functions in Pool Contract

Summary:

Certain functions that interact with critical state variables or external contracts fail to validate inputs thoroughly, specifically when dealing with addresses or parameters critical to the system's functionality. This oversight could lead to system instability or loss of functionality if invalid inputs are provided.

Description:

Some key functions in the contract fail to validate input parameters adequately, particularly when working with addresses or parameters that have downstream effects. Below are examples of such issues:

  1. setReserveInterestRateStrategyAddress: a, Validates that asset is a non-zero address but does not ensure that rateStrategyAddress is non-zero.
    b, Potentially allows an invalid address (address(0)) to be set for the interest rate strategy, which could disrupt core functionality.

  2. setLiquidationGracePeriod: a, Checks if asset exists but does not validate the until parameter. b, This can allow improper or malicious inputs, such as a timestamp in the past or an unreasonably large value, leading to unexpected or unintended behavior.

Root Cause:

Failure to perform complete input validation in the following lines of code (LoC):

  1. setReserveInterestRateStrategyAddress (LoC: XXX): 
    require(asset != address(0), "Errors.ZERO_ADDRESS_NOT_VALID");
_rateStrategies[asset] = rateStrategyAddress; // No validation for rateStrategyAddress

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/pool/Pool.sol#L642-L650

  1. setLiquidationGracePeriod (LoC: 805): 
    require(assets[asset].exists, "Errors.INVALID_ASSET");
assets[asset].liquidationGracePeriodUntil = until; // No validation for until parameter

LoC

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/pool/Pool.sol#L805-L811

Impact:

  • Setting invalid inputs (e.g., address(0) for a critical address or improper timestamps) can cause the following risks:
    • Loss of functionality: Invalid addresses or parameters may render critical processes inoperable.
    • System instability: Malicious inputs could destabilize the system, leading to potential financial losses or downtime.
    • Operational complexity: Troubleshooting and rectifying invalid states increase the operational burden.

Proof of Concept (PoC):

  1. Unchecked rateStrategyAddress in setReserveInterestRateStrategyAddress:

    • Call the function with a valid asset but rateStrategyAddress = address(0): 
      contract.setReserveInterestRateStrategyAddress(0x123456789abcdef, address(0));
    • Result: The rateStrategyAddress for the asset is set to address(0), causing disruption.

  2. Improper until parameter in setLiquidationGracePeriod:

    • Call the function with a valid asset but until set to a timestamp in the past: 
      contract.setLiquidationGracePeriod(0x123456789abcdef, block.timestamp - 1);
    • Result: The liquidationGracePeriodUntil is set to a value that is already expired, destabilizing the liquidation process.

Recommended Mitigation:

  1. Enhance Validation in setReserveInterestRateStrategyAddress:

    • Add a check to ensure that rateStrategyAddress is non-zero: 
      require(rateStrategyAddress != address(0), "Errors.ZERO_ADDRESS_NOT_VALID");

  2. Enhance Validation in setLiquidationGracePeriod:

    • Add a check to ensure that the until parameter is a valid timestamp in the future: 
      require(until > block.timestamp, "Errors.INVALID_TIMESTAMP");

By introducing these validations, the contract will be protected against invalid inputs that could compromise its functionality or security.