Closed sherlock-admin2 closed 1 year ago
2 comment(s) were left on this issue during the judging contest.
panprog commented:
low, because it's not possible to profitably manipulate liquidity withdrawal - any change from the "current" price will lead to liquidity withdrawn to be higher value (calculated at current price) , and any manipulator will incur loss from such manipulation
MohammedRizwan commented:
valid
0x007
high
Liquidator could reverse LP sandwich _uniswapWithdraw and easily cause bad debts for Lenders
Summary
_uniswapWithdraw
is a function that burns LP tokens but there's no check on min amounts. This could be used by liquidator to extract value from Borrower and cause bad debts for Lender.Vulnerability Detail
Reverse LP sandwich are MEV that target LP modifications such as add liquidity and burn liquidity. Explanation is provided in this medium article.
The process we care about in the liquidate function is as follows
_getAssets
->_uniswapWithdraw
->UNISWAP_POOL.burn
min(liability, tokenBalance)
The issue is that the burnt amount is not checked against any baseline. The liquidator and every MEV searcher are trusted to behave in the best interest of the Protocol. But they shouldn't.
The withdrawn asset could be too skewed or too low to cover the whole liabilities. The loser is the Borrower but this loss would easily spread to Lender in the form of bad debt.
This attack could be executed with a single transaction with flash loan
Impact
Sandwich against
_uniswapWithdraw
would cause loss to depositors of Lender contract.Code Snippet
https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/Borrower.sol#L209 https://github.com/sherlock-audit/2023-10-aloe/blob/main/aloe-ii/core/src/Borrower.sol#L231-L232
Tool used
Manual Review
Recommendation
Consider comparing
burn+collected
amount againstassets.fluid0C
andassets.fluid1C
with a slippage percentage like 1%.