Flow

Summary

Potential issues arise from the usage of custom data types (UD60x18 and UD21x18) from the PRB math library without appropriate validation checks, which may lead to unexpected behaviors and incorrect calculations.

Finding Description

The contract utilizes UD60x18 and UD21x18 data types to represent fixed-point numbers. However, if these types are not properly validated upon input or usage, it could lead to inaccuracies in calculations or unintended states. For instance, if a value that exceeds the allowable range for these types is passed, it could cause calculations to yield incorrect results or revert unexpectedly.

These vulnerabilities break the security guarantees of correctness and reliability, as they can lead to unexpected behavior in financial calculations, impacting users' trust and the contract's operational integrity.

If a malicious actor provides a value that is outside the expected range when calling functions that involve these data types, it could propagate through the system, leading to failure in financial operations, incorrect fee calculations, or improper state changes.

Vulnerability Details

• Data Type Limits: The UD60x18 type represents fixed-point numbers with 18 decimal places, while UD21x18 allows for significantly large numbers. Without validating that inputs conform to expected formats and ranges, the contract is susceptible to incorrect calculations and state manipulation.

• Usage Without Validation: The contract performs operations using these types without checks to ensure the validity of the inputs, potentially leading to underflows, overflows, or other unintended behaviors.

Impact

The impact assessment is considered high due to the potential financial ramifications of inaccurate calculations. If users interact with the contract assuming correctness, and the contract yields erroneous results or behaves unexpectedly, it could result in significant financial losses or exploitation opportunities for malicious actors. Such vulnerabilities could also damage the project's reputation, leading to decreased user trust.

Proof of Concept

While there is no specific malicious input example provided in the current contract, consider the following scenario:

1. A function that sets a protocol fee using the setProtocolFee function is called with an excessively high value that exceeds the maximum allowed by UD60x18.

2. If this value is processed without validation, it could propagate through calculations in other functions that rely on this fee, leading to incorrect financial states, such as overcharging users or failing transactions due to calculations that exceed the allowed range.

Recommendations

To mitigate this issue, it's essential to implement proper validation for all input parameters that utilize UD60x18 and UD21x18. This includes:

1. Input Validation: Ensure that any value passed to functions that accept these types is within the expected range and format.

2. Checks Before Assignment: Add checks before setting these values in state variables to ensure they meet the contract's expectations.

Here’s an example of a modified setProtocolFee function with added validation:

By adding checks and validations for the custom data types, the integrity and reliability of the contract can be significantly improved, thus protecting against potential financial mishaps and maintaining user trust.

File Location

SablierFlowBase.sol