Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rhythmic Charcoal Caribou - Two Pyth Prices Can Be Used in the Same Transaction to Attack LP Pools (Oracleless Contract) #892

Open
sherlock-admin2 opened this issue Dec 9, 2024 · 0 comments

Comments

@sherlock-admin2
Copy link

Rhythmic Charcoal Caribou

High

Two Pyth Prices Can Be Used in the Same Transaction to Attack LP Pools (Oracleless Contract)

Summary

The vulnerability arises in the context of Oracleless Contracts that integrate with Pyth oracles. The issue is similar to that found in other contracts using the Pyth oracle. The key problem is that there are no guarantees that the price at the current time is the freshest. This flaw can be exploited by an attacker to manipulate the price at the time of an LP position deposit and withdrawal, resulting in a risk-free profit.

In these Oracleless contracts, the lack of an additional freshness check for the price, beyond the age of the price (maxAge), allows attackers to manipulate the system by entering and exiting LP positions at different prices within the same transaction.

Root Cause

The Pyth oracle in Oracleless contracts provides prices from offline sources. The protocol does not ensure that the price retrieved at any given moment is the most up-to-date, leaving the potential for an attacker to exploit price discrepancies.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

In the contract, an attacker can:
Place an open order at a lower price (when the price is favorable).
Cancel the order and modify the price to a higher value (by updating the price using fillOrder or modifyOrder).
Place a new order at the higher price and execute the trade at the newly updated price.

Impact

An attacker could place an order at a low price (e.g., at the start of the transaction), cancel the order, then modify it to a higher price in the same transaction and fill the order at that higher price. This would result in the attacker profiting from the price difference with no risk of loss.

PoC

No response

Mitigation

Introduce a mechanism to ensure that the price used for order creation, modification, and cancellation is consistent and up-to-date. A freshness check should be enforced to prevent discrepancies between different stages of order processing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant