Skip to content

Latest commit

 

History

History
66 lines (45 loc) · 3.18 KB

011.md

File metadata and controls

66 lines (45 loc) · 3.18 KB

Obedient Lava Monkey

Medium

Lack of Bounds Checking in getFlags and getParams Functions

Summary

The absence of bounds checking in the getFlags and getParams functions will cause unexpected protocol behavior for users and the protocol as corrupted or out-of-bounds configuration data will result in invalid or nonsensical reserve parameters being returned and acted upon.

Root Cause

In ReserveConfiguration.sol, the getFlags and getParams functions directly return values derived from self.data without validating whether these values fall within acceptable ranges or configurations.

return (dataLocal & LTV_MASK);

In ReserveConfiguration.sol, the getFlags function directly returns flags derived from self.data without validating whether the data field contains valid configurations. Specifically:

return (
  (dataLocal & ACTIVE_MASK) != 0,
  (dataLocal & FROZEN_MASK) != 0,
  (dataLocal & BORROWING_MASK) != 0,
  (dataLocal & PAUSED_MASK) != 0
);

If self.data contains corrupted or unintended values (e.g., due to improper updates elsewhere in the system), the function will return invalid flags, leading to protocol misbehavior. This is not hypothetical because bitwise operations do not inherently validate input correctness, and no validation exists here to ensure data integrity.

Internal Pre-conditions

  1. An admin or external contract improperly updates the data field of ReserveConfigurationMap to include invalid or out-of-bounds values.
  2. Corrupted or unintended bit values are stored in critical parameters such as LTV, Liquidation Threshold, or flags.

External Pre-conditions

  1. The protocol executes operations relying on the corrupted configuration data.
  2. External actors interact with the protocol, triggering actions based on invalid configurations (e.g., borrowing, liquidation, or supplying assets).

Attack Path

  1. Corrupted or out-of-bounds data is present in ReserveConfigurationMap.data due to an improper update or a bug elsewhere in the system.
  2. A user action triggers functions relying on getFlags or getParams, which return invalid values without validation.
  3. These invalid values affect protocol behavior, such as:
  • Allowing excessive borrowing due to invalid LTV.
  • Improper liquidation actions due to incorrect Liquidation Threshold.
  • Unexpected toggling of critical flags such as Active or Paused.

Impact

The protocol suffers potential loss of consistency and trust due to:

  • Erroneous reserve behavior, such as over-lending or incorrect liquidations.
  • Financial loss for users interacting with improperly configured reserves.

PoC

No response

Mitigation

Introduce sanity checks in the getFlags and getParams functions to validate returned values are within valid ranges:

require(returnedValue <= MAX_VALID_LTV, "Invalid LTV value");