Open code423n4 opened 3 years ago
Good point on the strict check of fast gas price. As you pointed out this is to prevent gas auctions from occuring and causing liquidations to be extremely expensive, however this could become a bottleneck in times of rapidly changing gas prices.
Have acknowledged that this could cause problems in certain scenarios. The team will be thinking about a safer implementation of this mechanism.
Handle
0xRajeev
Vulnerability details
Impact
In verifyAndSubmitLiquidation(), the tx.gasprice is checked against the fastGasOracle’s current gas price presumably to prevent liquidators front-running others for the same market/account by using a gas price exceeding the current prevailing price as indicated by the fastGasOracle.
Impact: If the gas prices are increasing rapidly due to volatility or network congestion, or if the liquidation engines and fastGasOracle are out of sync on gas prices because of consulting different sources, then these liquidations will keep failing. Front-running risk on liquidations is not adequately protected by tx.gasprice check.
This logic may also be impacted by the upcoming inclusion of EIP-1559 in London fork which affect gas semantics significantly.
Proof of Concept
https://github.com/code-423n4/2021-06-tracer/blob/74e720ee100fd027c592ea44f272231ad4dfa2ab/src/contracts/Liquidation.sol#L156
Tools Used
Manual Analysis
Recommended Mitigation Steps
Liquidation bots front-running by monitoring mempool or the use of FlashBots for liquidation MEV is a systemic challenge and not solved by using gasprice logic in contracts. Evaluate if the benefits match the failure modes.