Pull Based Oracle opens up to triggering Recovery Mode and liquidating other Troves as a risk free arbitrage

criticalRecon Audits

Executive Summary

Pull Based oracle can be viewed as offering an attacker the ability to chose a combination of price that are not stale

This, combined with the possibility of lowering the TCR down via ones own positions opens up to a risk free arbitrage in which an attacker drags the TCR down to trigger Recovery Mode, and then they liquidate other people troves

Description

<img width="629" alt="Screenshot 2024-08-08 at 11 26 02" src="https://github.com/user-attachments/assets/6d3e67ef-fa98-43cc-831f-582671ca8aea">

Pyth Pull Oracles can be viewed as a sequence of prices, p0 to pn where any ordered sequence p0 -> px -> pn can be picked as long as all prices are within the staleness threshold

Recovery Mode allows healthy Troves to be liquidated when the TCR falls below a certain threshold

Liquidations can be performed arbitrarily and out of order, as long as a Trove meets the requirements for Liquidations

Due to this, an attacker can push the TCR down very close to Recovery Mode and then update prices to a more negative price to trigger Recovery Mode, and perform liquidations.

This is a risk free opportunity that could be abused any time the threshold for profit is met:

• Profit = Gain from Liquidation * Ownership % - Opening Fees - Gas Costs

POC

• Wait for a price sequence that will result in a decrease of TCR
• Use the older price (healthier price)
• Flashloan funds, borrow to bring the TCR very close to Recovery Mode
• Deposit into the Stability Pool, ideally a very high amount to maximize profits
• Update Prices, Recovery Mode is triggered
• Liquidate other Troves (ideally out of order, to liquidate a higher amount of collateral)
• Attacker closes their position

Mitigation

A few ideas for mitigation:

• Offer a Grace Period in which Recovery Mode liquidations cannot happen, this can be a short delay (e.g. 15 minutes), which should allow victims to react (as long as they have setup monitoring and automations) - This is the safer option with the clear downside of a risk of desynching the state (as Recovery Mode may be engaged, but the timer would require an external call to be triggered)

• You could enforce a different ratio at which opening Troves can be performed, but this would limit opening CRs always above the CCR, a buffer could be gamed by setting up Troves that over time have their CR below the CCR, or by setting up a very heathy Trove and then closing it

• You may explore whether it's possible to always use the latest Pyth Price and enforce that only the latest price is used, this main risk would be the inability to perform operations anytime a transaction was in the mempool for too long

Also note that because you have a mixture of Collaterals and Debt Tokens, the opportunity to trigger Recovery Mode is higher than if you only used a single Collateral and Debt Pair