Open c4-bot-7 opened 8 months ago
0xEVom marked the issue as duplicate of #412
0xEVom marked the issue as sufficient quality report
0xEVom marked the issue as not a duplicate
0xEVom marked the issue as primary issue
Most likely a design choice, but leaving it open for the sponsor to review.
Yeah its a design choice and we probably will add a safety buffer on the frontend. But in contract it is not needed
kalinbas (sponsor) disputed
I think this is a valid M, as typically the safety measures added at the frontend are considered unreliable. I don't quite understand the significant benefits of the current design; it only slightly increases capital efficiency but exposes users to liquidation risks.
Temporarily marked as M, but awaiting further review by the sponsor.
jhsagd76 changed the severity to 2 (Med Risk)
jhsagd76 marked the issue as satisfactory
jhsagd76 marked the issue as selected for report
Agreed. Will add this safety buffer
kalinbas (sponsor) confirmed
Lines of code
https://github.com/code-423n4/2024-03-revert-lend/blob/main/src/V3Vault.sol#L1278
Vulnerability details
Description
The
_checkLoanIsHealthy
function is used in theV3Vault
to assess a user’s given position and determine the health factor of the loan. As there is no safety buffer when checking the health factor of a given position, users could be subject to a negative health factor if there are minor movements in the market which could result in liquidation or in the worst case scenario, an attacker could force a liquidation on a user and profit by sinking their position in the Uniswap pool.Vulnerability Details
The
_checkLoanIsHealthy
function holds the implementation to check if a users position is healthy and will return false if the position not able to be liquidated by obtaining the full value of the collateral inclusive of fees through the oracle by thetokenId
. ThecollateralValue
is then calculated from_calculateTokenCollateralFactorX32
. Finally, we return whether thecollateralValue
is greater than or equal to the debt requested:However, the issue in the code is that the the start of the liquidation threshold (Ie. 85%) is supposed to be greater than the loan to value ratio (Ie. 80%) to create some breathing room for the user and reduce the risk of the protocol incurring bad debt.
Impact
Borrowers of the protocol may be unfairly liquidated due to minor movements in the market when taking out the max loan. In the worst case scenario, a user could be subject to a forced liquidation by the attacker (a malicious user or a bot) for profit.
Proof of Concept
The proof of concept below simulates a scenario where a user takes out a loan. The malicious user creates some small movements in the market in order to purposely sink a user’s position. The malicious user then liquidates the victim for profit forked from the Ethereum mainnet:
Tools Used
Manual review
Recommended Mitigation Steps
Consider implementing a safety buffer for the users position which is considered when attempting to take out a loan so that they are not subject to liquidations due to minor changes in the market. For instance, if the liquidation threshold is at 80%, the borrower’s max loan is at 75% of that ratio. After some small changes in market conditions the position is now at a 75.00002% and is still safe from liquidations as it is still over collateralised. This can be done by implementing this as another state variable and checking that the requested debt is initially below this threshold. When attempting to liquidate, the health of the position is then checked against the liquidation threshold.
Assessed type
Other