Front-running vulnerability in pool price setting function

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-08-superposition/blob/4528c9d2dbe1550d2660dac903a8246076044905/pkg/seawater/src/lib.rs#L1089

Vulnerability details

The SeawaterAMM contract contains a function setSqrtPriceFF4DB98C() that allows the admin to change the price of a pool. However, this function is vulnerable to front-running attacks, allowing malicious actors to profit from the price change. The core issue lies in the atomic nature of the price change. Once an admin submits a transaction to change the price, this intention becomes visible in the mempool before it's executed. This window of visibility allows attackers to craft and submit their own transactions that will be executed before the price change, effectively allowing them to trade with foreknowledge of the future price.

Impact

Direct financial exploitation:

• An attacker can monitor the mempool for pending price change transactions.
• Upon detecting an impending price increase, the attacker can quickly buy tokens at the current lower price.
• After the price change is executed, the attacker can immediately sell the tokens at the new, higher price for a guaranteed profit.

Proof of Concept

1. Alice, an attacker, monitors the mempool for calls to setSqrtPriceFF4DB98C().
2. Alice sees a transaction that will increase the price of TokenA in a specific pool.
3. Alice quickly submits a transaction to buy TokenA at the current (lower) price.
4. The price change transaction is executed, increasing the value of TokenA.
5. Alice immediately sells her TokenA for a profit.

Tools Used

Manual review

Recommended Mitigation Steps

Ensure that the pool is not enabled before changing the price.

Assessed type

Other

[af-afk]

We're not going to resolve this because this function will be used by the DAO in the event that a price becomes stuck, or in a programmatic context (maybe the setting of odds for example).

[alex-ppg]

The submission states that a direct price adjustment via an administrative action might be insecure to perform and may ultimately be exploited, however, the issue relies on the administrator making a mistake (i.e. updating the square root price without pausing the pool beforehand).

While restrictions might be imposed on when the function can be invoked, it remains an administrative function that we expect the Sponsor to responsibly utilize per the relevant SC verdicts rendering this submission to be a QA recommendation.

[c4-judge]

alex-ppg changed the severity to QA (Quality Assurance)

[c4-judge]

alex-ppg marked the issue as grade-c

[c4-judge]

alex-ppg marked the issue as grade-b