almurhasan - user/MEV can frontrun and backrun the oracle update of an rETH price and steal funds from the protocol(Possible arbitrage from oracle price discrepancy ) #46
user/MEV can frontrun and backrun the oracle update of an rETH price and steal funds from the protocol(Possible arbitrage from oracle price discrepancy )
Summary
The problem is that a user can know which direction the oracle price of a rETH will move, before it does, either through watching the rETH price move in advance of the oracle updating, or watching the mempool for oracle update transactions and frontrunning them.
Vulnerability Detail
Let’s take example , let assume
1e18 rETHl price = 1e18 , now the exchange rate of the asset will be updated to 1e18 rETH price = 0.95e18..
user/MEV can frontrun and let assume users mint 100 UNIT (as oracle price is still not updated yet) . After the oracle price is updated, the user can backrun(withdraw his 100 UNIT) because 100 UNIT is now worth 105 rETH. So user/mev make a profit of 5 rETH.
This can also happen in opposite direction,let assume
1 rETH price = 1 , now the exchange rate of the asset will be updated to 1 rETH price = 1.05 .user/MEV(previously deposited) can frontrun and withdraw 100 UNIT (as oracle price is still not updated yet).After the oracle price is updated, the user can backrun and deposit 100 rETH, and get 105 UNIT .
implementing a 1 hour waiting period on deposit/ withdraw or
storing minting and redemptions and executing them at a future exchange rate or creating pause/unpause for minting/redeeming .
Invalid, front-running is not possible on base, given they use a private mempool see discussions here and comments here. Additionally, the whole protocol has delayed orders implemented based on executability ages to mitigate this.
almurhasan
high
user/MEV can frontrun and backrun the oracle update of an rETH price and steal funds from the protocol(Possible arbitrage from oracle price discrepancy )
Summary
The problem is that a user can know which direction the oracle price of a rETH will move, before it does, either through watching the rETH price move in advance of the oracle updating, or watching the mempool for oracle update transactions and frontrunning them.
Vulnerability Detail
Let’s take example , let assume 1e18 rETHl price = 1e18 , now the exchange rate of the asset will be updated to 1e18 rETH price = 0.95e18.. user/MEV can frontrun and let assume users mint 100 UNIT (as oracle price is still not updated yet) . After the oracle price is updated, the user can backrun(withdraw his 100 UNIT) because 100 UNIT is now worth 105 rETH. So user/mev make a profit of 5 rETH.
This can also happen in opposite direction,let assume 1 rETH price = 1 , now the exchange rate of the asset will be updated to 1 rETH price = 1.05 .user/MEV(previously deposited) can frontrun and withdraw 100 UNIT (as oracle price is still not updated yet).After the oracle price is updated, the user can backrun and deposit 100 rETH, and get 105 UNIT .
Impact
Attackers can gain profit and steal collateral .
Code Snippet
https://github.com/sherlock-audit/2023-12-flatmoney/blob/main/flatcoin-v1/src/StableModule.sol#L70
Tool used
Manual Review
Recommendation
implementing a 1 hour waiting period on deposit/ withdraw or storing minting and redemptions and executing them at a future exchange rate or creating pause/unpause for minting/redeeming .