Updating closed ranges with overrideRange() causes incorrect prevRangeClosePrice.

[c4-submissions]

Lines of code

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

Vulnerability details

Impact

• Incorrect starting prices for ranges
• Incorrect historical price derivations
• Loss of accurate price data history

Proof of Concept

updating closed ranges with overrideRange() can cause an incorrect prevRangeClosePrice value. Here is a more detailed explanation:

The prevRangeClosePrice is intended to be the derived price from the previous range at the end of that range. This value is then used as the starting price for the next range.

The issue occurs if you call overrideRange() on a closed range. For example:

Range 1:
Start: 1000
End: 2000
prevRangeClosePrice: 10

Range 2:
Start: 2000
End: 3000
prevRangeClosePrice: 20

If you then call overrideRange() to modify Range 1 after it is already closed:

overrideRange(0, 1500, 2500, 5%, 30)

This will update Range 1 but leave Range 2's prevRangeClosePrice as 20. When in reality, based on the new Range 1 values, the prevRangeClosePrice for Range 2 should be 25.

So Range 2's starting price is now incorrect based on the previous range.

This happens because overrideRange() just overwrites the closed range values without recalculating subsequent ranges.

Tools Used

Manual

Recommended Mitigation Steps

Recalculate all subsequent range's prevRangeClosePrices if a closed range is overridden

Assessed type

Other

[raymondfam]

From readme:

We are aware that if a range is updated the prevRangeClosePrice for subsequent set ranges will be stale.

[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