Price Oracle Manipulation Through Front-Running in YieldOracle

[hats-bug-reporter[bot]]

Github username: -- Twitter username: 0xgreed_ Submission hash (on-chain): 0x4c9c017bf1a635da2de09e3e7b88ff6d73ed640ea8b4d4bc156e07e7147ba8a5 Severity: medium

Description:

Relevant Context

The YieldOracle contract manages price updates through a two-step process:

1. The oracle calls updatePrice() to set a new price
2. After a delay, anyone can call commitPrice() to make the price effective

The contract tracks three price values:

• previousPrice: Used for sharesToAssets() calculations
• currentPrice: Used for assetsToShares() calculations
• nextPrice: Pending price waiting to be committed

Finding Description

The two-step price update mechanism combined with the use of previousPrice for share-to-asset conversions creates an opportunity of a high return trade. An attacker can monitor for commitPrice() transactions and execute the following attack:

1. Front-run the commitPrice() transaction by buying tokens when price is low
2. Wait for price update in the same block
3. Sell tokens after price increases

The vulnerability is exacerbated by using previousPrice in sharesToAssets() instead of currentPrice, which means the attacker can only profit from price differences across minimum two update cycles. But this doesn't mean the attack is not profitable and not possible.

Impact Explanation

Medium. This vulnerability allows attackers to extract value from the protocol by exploiting price updates, while not participating to the benefit of the protocol.

Likelihood Explanation

Medium. The attack requires no special permissions or complex setup, just the ability to monitor and front-run transactions which is common in DeFi. The profit potential makes this attack highly likely to be exploited by any attacker and mev searchers.

Proof of Concept

1. Attacker monitors mempool for commitPrice() transaction (which is with a higher price than the current one, as the protocol force it)
2. When detected, attacker front-runs by:
   • Converting assets to shares using assetsToShares() at current low price
3. commitPrice() executes, setting new higher nextPrice
4. Attacker converts shares back to assets using sharesToAssets(), profiting from price difference

Recommendation

Add minimum holding periods before shares can be minted.

[AndreiMVP]

As you say

attacker can only profit from price differences across minimum two update cycles

that's the intended effect; while the user would collect one batch of yield profit, Eurodollar should also produce proportional yield. This might be the best profit scenario for the user but on average it should not negatively affect the protocol/organization economically as far as I can tell.