Full report: Curve exposed for oracle manipulation vulnerability

Author: Daniel Von Fange

Compiled by: angelilu, Foresight News

Yesterday, independent researcher Daniel Von Fange disclosed on the X platform in a post that Curve has a risk of oracle manipulation, which is difficult to detect during an attack. Oracle manipulation can lead to oracles reporting incorrect data about external events or the real world, putting protocols that access these oracles at risk of manipulation as well. Daniel Von Fange stated that he has notified the relevant teams that may be affected.

Curve founder Michael Egorov responded to the issue in the community, stating that "this risk may exist in older versions of pools, crvusd does not use old version pools, and oracles are not recommended." He also confirmed that the risks disclosed by Daniel Von Fange do indeed exist.

However, Curve contributor fiddy expressed discontent with the way this independent researcher publicly released this information without discussion, and issued a clarification stating that the vulnerabilities disclosed by Daniel Von Fange had previously been discussed privately. He believes that the cost of increasing gas fees for attackers to improve precision is high, and external audits have classified this as low impact. Furthermore, the vulnerability disclosed by the researcher is related to Curve's older cryptoswap algorithm, which used last_price pricing, while the newer cryptoswap-ng implementation uses AMM state prices, which can resolve such issues. Additionally, yAuditDAO has indeed found some errors in the oracles, which are currently being fixed, and no one is using these oracles, and the LPs (liquidity providers) in these stablecoin trading pools are not affected.

However, some teams have begun to adjust their protocols based on the disclosed risks to enhance security. Yearn Finance developer @storming0x also responded to the risks disclosed by Daniel Von Fange, stating that "Yearn contracts are not affected, except for one contract that uses a Chainlink redundancy mechanism to mitigate potential attack paths. Out of caution, the Yearn development team decided to redeploy a new version."

Below is the full text of Daniel Von Fange's disclosure regarding the risk of price manipulation in Curve oracles:

Over the past two weeks, I have conducted an in-depth study of Curve's price oracles and discovered some extremely abnormal behaviors.

The operation of these oracles is not as you might think; they are easier to manipulate than expected and may also go wrong under normal circumstances.

In brief: in most pools, an attacker can manipulate Curve's price oracle to be 10 to 500 times higher than the normal price in just one block. Moreover, this manipulation can be hidden to the extent that there are no signs of manipulation when viewing the pool.

There are many Curve pools, and no one has been able to accurately count the number of different pool codebases.

What I have written may apply to certain specific pools and may not apply to others. Different pools have different vulnerabilities. Some pools may have no vulnerabilities at all.

The Curve team has performed excellently in receiving reports and discussions, confirming within minutes that CrvUSD is not affected by these issues.

I also checked about 100 contracts on the mainnet that use Curve price oracles and notified the relevant teams as appropriate.

A key issue with the vulnerability is that when the price is not close to 1:1 or when transaction fees are high, last_price may be miscalculated.

First, transaction fees are not included in the last_price calculation, which makes the number it uses different from the actual transaction or pool balance.

The EMA price oracle is driven by lastprice. When lastprice is incorrect, the price oracle will begin to move towards the wrong target price.

In normal trading, I have seen the price oracle's targeted price deviate from the actual current price in the pool by more than one percent. The worst-case scenario could be even worse (the standardized price in the chart).

Depending on the pool, this drift error may be higher or lower than the actual price.

The biggest problem is that during manipulation, the last_price error may be an order of magnitude higher than the actual manipulated price, greatly increasing the likelihood that the pool oracle is effectively manipulated.

Even a very small transaction can correct the deviation in the last price/oracle price, leading to some absurd situations.

Due to the combined effects of significant price fluctuations and last_price calculation errors, attackers can manipulate the EMA price oracle in the next block without incurring huge costs to maintain a high price over dozens of blocks to counter arbitrageurs.

Theoretically, attackers can control the mining of two consecutive blocks, which is necessary to achieve this operation. Attackers need to have sufficient capital for such price attacks, but many past attackers have had tens of millions of dollars in funds.

Next, let's talk about common strategies to defend against Curve price oracle manipulation and their effectiveness.

Curve v1 pools have four numbers that can be used to attempt to detect manipulation: actual price, price oracle, lastprice, and EMA price. Unfortunately, after a manipulation, a single transaction manipulating the priceoracle can reset all of these to the same number.

The pricescale of Curve v2 pools is harder to manipulate than the price oracle. It changes more slowly and requires actual transaction fee costs to move. If this fast price oracle matches the slow pricescale, then the situation stabilizes, right?

No! The core attack issue is aligning the three numbers: actual price, fast oracle, and slow scale. The actual price is easy to control because it can be manipulated immediately. The question then becomes designing an intersection between the other two.

The attacker will briefly raise the price, then return to normal in the next block, and wait for several blocks to attack until the declining price oracle meets the rising pricescale. The actual price only needs to be maintained at a high level for one block to disrupt the oracle, and the pricescale will follow.

Many oracles use caps, limiting the prices they use from Curve oracle prices to a maximum of 1:1. This is good and excludes foolishly high values. But note that if the asset actually decouples, an attacker can buy the asset at a low price and then manipulate it to make it appear re-pegged.

Protocols sometimes set a minimum threshold, and if the response of the Curve price oracle is below a certain percentage of the peg, it will be ignored. But if the price is ignored when the asset truly decouples, then the entire purpose of having a price oracle is lost.

Another common strategy is to mix in the price of another AMM system. This largely depends on the quality and manipulation characteristics of other pools. If it has lower liquidity and is easier to manipulate, then the goal is not achieved.

Bad + Bad = Bad.

The new type of Curve pool for stablecoin/stablecoin trading pairs limits lastprice to twice the 1:1 value. This can prevent a one-block attack because lastprice cannot be pushed to foolishly high values, thus overloading the EMA.

But if the wrong asset legitimately decouples, then that is a mistake.

If you want to use Curve pools to price collateral assets, you probably shouldn't do so.

New pools typically have higher attack costs. If the manipulated pool has a small market impact (possibly just to protect yield distribution), and the cost of simulating attacks against the pool is high, then it may be chosen for use.

Finally, the author suggests conducting actual attack simulations on the pools used, rather than predicting the behavior of price oracles based on assumptions or theories, and performing detailed simulation tests on the pools in actual use. By simulating manipulation attacks, a better understanding of the pool's performance under different conditions can be achieved.

The following chart shows the increase in the usage of Curve oracles over the past 90 days:

Some Curve pools have price oracles that perform excellently, and I could not make them exhibit any strange behavior; they fully meet the expectations of a well-performing EMA. But they still need to be checked…