Absence of Start-End Time Validation in Range Creation

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-09-ondo/blob/47d34d6d4a5303af5f46e907ac2292e6a7745f6c/contracts/rwaOracles/RWADynamicOracle.sol#L111

Vulnerability details

The code allows the creation of a Range structure without ensuring that startTime is strictly less than endTime. The absence of this validation might lead to unintended behavior or logical errors in functionalities that rely on the order of these timestamps.

Impact

Inverse Range: Creating a range where endTime is earlier than startTime could lead to functions that depend on the time range to malfunction or return unintended results.

Zero-Length Range: If both startTime and endTime are the same, the range would effectively represent zero duration, which might cause miscalculations in time-based functionalities.

Any external contracts or operations relying on the correct ordering of startTime and endTime might fail or produce unexpected outcomes.

Potential Denial of Service or logic loops if functions assume endTime is always greater than startTime.

Proof of Concept

Alice attempts to create a new Range with startTime set to a timestamp of 2023-12-15 and endTime set to 2023-12-01.

The contract allows the creation without any validation checks.

Bob, relying on the Range for a time-based calculation, fetches the range. However, due to the inverse order, his calculations fail or produce an incorrect result.

Carol, another user, tries to calculate a duration based on the same range and mistakenly assumes a duration of 14 days, when in fact the range is logically invalid.

Tools Used

Recommended Mitigation Steps

Introduce a validation step during the creation or modification of a Range to ensure that startTime is strictly less than endTime.

Implement appropriate error messages to inform the user or caller of the specific validation failure.

Expand test coverage to include scenarios where startTime and endTime are inverse or equal to ensure the contract behaves as expected.

Assessed type

Invalid Validation

[raymondfam]

It's only a simulation. At worst, the wrong setting would just revert the function when calling derivePrice that encounters underflow.

[c4-pre-sort]

raymondfam marked the issue as low quality report

[c4-pre-sort]

raymondfam marked the issue as primary issue

[c4-pre-sort]

raymondfam marked the issue as duplicate of #25

[c4-judge]

kirk-baird marked the issue as unsatisfactory: Invalid