Closed c4-bot-4 closed 6 months ago
This is intended - see honest admin assumption.
bytes032 marked the issue as insufficient quality report
The Warden details how the liquidation threshold for troves can be arbitrarily changed by the administrators of the Opus system.
This falls under centralization concerns and should be outlined in an Analysis report rather than submitted as an HM finding per the relevant SC verdict.
alex-ppg marked the issue as unsatisfactory: Invalid
alex-ppg marked the issue as primary issue
alex-ppg marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-01-opus/blob/4720e9481a4fb20f4ab4140f9cc391a23ede3817/src/core/shrine.cairo#L622-L629 https://github.com/code-423n4/2024-01-opus/blob/4720e9481a4fb20f4ab4140f9cc391a23ede3817/src/core/shrine.cairo#L1357-L1368 https://github.com/code-423n4/2024-01-opus/blob/4720e9481a4fb20f4ab4140f9cc391a23ede3817/src/core/shrine.cairo#L171-L176 https://github.com/code-423n4/2024-01-opus/blob/4720e9481a4fb20f4ab4140f9cc391a23ede3817/src/core/shrine.cairo#L1262-L1274 https://github.com/code-423n4/2024-01-opus/blob/4720e9481a4fb20f4ab4140f9cc391a23ede3817/src/core/purger.cairo#L227-L231 https://github.com/code-423n4/2024-01-opus/blob/4720e9481a4fb20f4ab4140f9cc391a23ede3817/src/core/purger.cairo#L549-L578
Vulnerability details
Vulnerability Detail
Setting liquidation threshold per yang (see below) has no restriction to when it should be executed. The only safe time is before opening trove with affected yang.
Since we know for sure there will be adjustment in the future, in which there are troves currently active and the admin decided to change the threshold of certain yangs (without proper checking), it can cause unfair liquidation to trove owners affected.
Let's further discuss on how untimely threshold setting could exactly affects the liquidation. In the function liquidate, the first step is to get trove health of the trove we are trying to liquidate. This can be executed by the function below:
Let's focus on line 1059 (see above) and discuss further the function get_threshold_and_value, in which we can found this function (see below).
Please see line 1263 in above, it reads the value of threshold for a certain yang ID. Please remember that this thresholds mapping is being updated by set_threshold function that would be serve as a basis for triggering liquidation (ltv > threshold).
As you can see, in the process flow above, there are no timing restriction throughout the process and adjustment of threshold can be problematic, disrupting the threshold data in which the liquidation process is dependent upon.
Impact
Unfair liquidation of troves due to sudden change in threshold.
Proof of Concept
Here's the coded POC to illustrate the scenario of setting threshold that can cause unfair liquidation. Before running this POC, please do the following:
Result: Here we can see that the liquidation is successful after a sudden lowering of the threshold into 70% (threshold is lower than LTV triggers liquidation in 3rd part)
Tools Used
Manual Review, Starknet-Foundry
Recommended Mitigation Steps
There should be a requirement checking in executing the set_threshold function. This function should revert if there are current active troves that will be affected by the changes in threshold setting.
Apply also suspension of liquidation process for the troves that will be affected while making critical changes in threshold setting so we can avoid unfair liquidations.
Assessed type
Timing