LP can instantly arbitrage and drain any Maker by updating the Pyth price

Summary

An LP who turns malicious can arbitrage any Maker pool by self-frontrun and self-backrun a Pyth price update, thereby manipulating the pool shares exchange rate.

Furthermore, this attack can be done in combination with a flashloan, enabling an almost-complete draining of Maker LP pool.

Vulnerability Detail

The Pyth oracle setting allows users to fetch a signed price from the Wormhole messaging bridge, then transfer it to the Pyth contract to update the price. Since the user can act on a new price right away, this opens up room for instant-arbing as the market is dependent on the Pyth price.

While there is a mitigation in place for traders against an Oracle Maker (every orders must go through the relayer), depositing and withdrawing by LPs is not protected against such an attack.

This opens up room for an instant-arbing scenario that will allow a malicious LP to siphon away the pool, eventually draining it.

Proof of concept

Let's say:

Alice is a whitelisted LP.
Alice discovers this attack and decides to use it to extract value from the pool.
Alice notices that the Maker is currently having a 1 ETH long position (or any long position).
- If the Maker doesn't have a position, Alice can just open one by themselves.
- This attack also works if the Maker has a short position.

They can perform the following attack:

Alice notice that the current onchain Pyth price is still fresh, but not up-to-date.
- The new Pyth price is currently slightly higher than the onchain price.
Alice withdraw all liquidity first, to prevent admin from blocking their funds by unwhitelisting.
In one transaction, Alice:
- Deposit liquidity. They gets some shares back.
- Note that these funds can be flashloaned, so it must be assumed to be arbitrarily large.
- Update the Pyth price. Note that this price is higher than when they deposit.
- Withdraw liquidity. Because the Maker (thinks it) currently has some profits due to the higher price, it credits more funds to Alice.

Repeating this attack will eventually allow Alice to get away with much value before the admin can act.

This attack is easily possible without many of the conditions mentioned above:

In step 1, the price does not have to be "fresh, but not up-to-date". They only have to find two prices within the updatable range such that the old price is lower than the newer.
- For example, if the price 10 seconds ago is lower than the price 2 seconds ago, then they can arb on these two prices.
Alice can take a very small price difference, and amplify the arbitrage amount by using a large flashloan (possibly all of the chain's flashloanable TVL). This possibly drains the pool in just one or two txs.
If the Maker's net position is short, just reverse the price direction (i.e. new price has to be lower than old price).
Because the attack starts with a deposit and ends with a full withdraw, Alice does not lose any funds if the admin notices it and unwhitelist. They fully get away.

Impact

LP can drain the pool based on a very small price difference by the Pyth oracle.

Code Snippet

https://github.com/sherlock-audit/2024-02-perpetual/blob/main/perp-contract-v3/src/maker/OracleMaker.sol#L228

https://github.com/sherlock-audit/2024-02-perpetual/blob/main/perp-contract-v3/src/maker/SpotHedgeBaseMaker.sol#L303

Tool used

Manual Review

Recommendation

Providing and/or withdrawing liquidity (for either makers) should go through a relayer, much like the current setting for Oracle Maker traders. This will severely limit arbing possibilities (equal to that of the Oracle Maker), and will completely eliminate the possibility of flashloan.

Duplicate of #123