Skip to content
This repository has been archived by the owner on Jan 7, 2024. It is now read-only.

BugBusters - User will be forced liquidated #234

Open
sherlock-admin opened this issue Jul 4, 2023 · 9 comments
Open

BugBusters - User will be forced liquidated #234

sherlock-admin opened this issue Jul 4, 2023 · 9 comments
Labels
Escalation Resolved This issue's escalations have been approved/rejected Medium A valid Medium severity issue Reward A payout will be made for this issue Sponsor Confirmed The sponsor acknowledged this issue is valid Won't Fix The sponsor confirmed this issue will not be fixed

Comments

@sherlock-admin
Copy link
Contributor

BugBusters

high

User will be forced liquidated

Summary

The addMargin function have a vulnerability that can potentially lead to issues when the contract is paused. Users are unable to add margin during the paused state, which can leave them vulnerable to liquidation if their collateral value falls below the required threshold. Additionally, after the contract is unpaused, users can be subject to frontrunning, where their margin addition transactions can be exploited by other users.

Vulnerability Detail

To better understand how this vulnerabilities could be exploited, let's consider a scenario:

1): The contract owner pauses the contract due to some unforeseen circumstances or for maintenance purposes.

2): During the paused state, User A wants to add margin to their account. However, they are unable to do so since the contract prohibits margin addition while paused.

3): Meanwhile, the price of the collateral supporting User A's account experiences significant fluctuations, causing the value of their collateral to fall below the required threshold for maintenance.

4): While the contract is still paused, User A's account becomes eligible for liquidation.

5): After some time, the contract owner decides to unpause the contract, allowing normal operations to resume.

6): User A tries to add margin to their account after the contract is unpaused. However, before their transaction is processed, User B, who has been monitoring the pending transactions, notices User A's margin addition transaction and quickly frontruns it by submitting a higher gas price transaction to liquidate User A's account instead.

Now userA will be forcefully liquidated even tho he wants to add the margin.

You can read more from this link

Impact

The identified impact could be

1): Unfair Liquidations: Users can be unfairly liquidated if their margin addition transactions are frontrun by other users after the contract is unpaused. This can result in the loss of their collateral.

Code Snippet

https://github.com/sherlock-audit/2023-04-hubble-exchange/blob/main/hubble-protocol/contracts/MarginAccount.sol#L136-L156

Tool used

Manual Review

Recommendation

Implement a Fair Liquidation Mechanism: Introduce a delay or waiting period before executing liquidation transactions. This waiting period should provide sufficient time for users to address their collateral issues or add margin.

@github-actions github-actions bot added the Excluded Excluded by the judge without consulting the protocol or the senior label Jul 10, 2023
@sherlock-admin sherlock-admin added the Non-Reward This issue will not receive a payout label Jul 19, 2023
@Nabeel-javaid
Copy link

escalate for 10 USDC

I think this issue should be considered as valid. The validity of issue should be accepted. The report clearly shows how a protocol owner actions (pause) will result in unfair liquidations causing loss of funds to users.

Also it is unlikely that on unpause human users will be able to secure their positions before MEV/liquidation bots capture the available profit. Hence the loss is certain.

For reference, similar issues were consider valid in the recent contests on sherlock, you can check it here and here. Maintaining a consistent valid/invalid classification standard will be ideal here.

@sherlock-admin2
Copy link

escalate for 10 USDC

I think this issue should be considered as valid. The validity of issue should be accepted. The report clearly shows how a protocol owner actions (pause) will result in unfair liquidations causing loss of funds to users.

Also it is unlikely that on unpause human users will be able to secure their positions before MEV/liquidation bots capture the available profit. Hence the loss is certain.

For reference, similar issues were consider valid in the recent contests on sherlock, you can check it here and here. Maintaining a consistent valid/invalid classification standard will be ideal here.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

@sherlock-admin sherlock-admin added the Escalated This issue contains a pending escalation label Jul 19, 2023
@ctf-sec
Copy link
Collaborator

ctf-sec commented Jul 20, 2023

I mean if the liquidation cannot be paused then clearly a medium (there are similar past finding)

https://github.com/sherlock-audit/2023-04-hubble-exchange/blob/1f9a5ed0ca8f6004bbb7b099ecbb8ae796557849/hubble-protocol/contracts/MarginAccount.sol#L322

    function liquidateExactRepay(address trader, uint repay, uint idx, uint minSeizeAmount) external whenNotPaused {

But The liquidation is paused as well

so recommend severity is low

a optional fix is adding a grace period for user to add margin when unpause the liquidation and addMargin

@Nabeel-javaid
Copy link

Hey @ctf-sec
Adding more context, the problem is not that the liquidation functions can be paused or not, it is more of a front-running problem.

Liquidation functions cannot be paused individually, whole contract is paused which means that other functions with the whenNotPaused modifier cannot be accessed either.

So when the contract is un-paused, a user can be front-run before making the position healthy and is unfairly liquidated. For more reference see the following issue that are exactly the same .

Perrenial Contest Issue 190
Notional Contest Issue 203

I hope that added context will further help in judging.

@hrishibhat
Copy link

hrishibhat commented Jul 31, 2023

@ctf-sec
I understand this is how it is design but there is a loss due front-run during unpause.

@ctf-sec
Copy link
Collaborator

ctf-sec commented Jul 31, 2023

sherlock-audit/2023-04-blueberry-judging#118

seems like this issue has been historically judged as a medium

then a medium is fine

@hrishibhat hrishibhat added Medium A valid Medium severity issue and removed Non-Reward This issue will not receive a payout Excluded Excluded by the judge without consulting the protocol or the senior labels Aug 2, 2023
@sherlock-admin sherlock-admin added Non-Reward This issue will not receive a payout labels Aug 2, 2023
@hrishibhat
Copy link

hrishibhat commented Aug 2, 2023

Result:
Medium
Unique
After further discussions with Lead Watson and Sponsor, considering this a valid medium based on the above comments

@sherlock-admin2
Copy link

sherlock-admin2 commented Aug 2, 2023

Escalations have been resolved successfully!

Escalation status:

@hrishibhat hrishibhat reopened this Aug 2, 2023
@sherlock-admin sherlock-admin added Reward A payout will be made for this issue and removed Non-Reward This issue will not receive a payout Escalated This issue contains a pending escalation labels Aug 2, 2023
@sherlock-admin2 sherlock-admin2 added the Escalation Resolved This issue's escalations have been approved/rejected label Aug 2, 2023
@0xshinobii 0xshinobii added Sponsor Confirmed The sponsor acknowledged this issue is valid Won't Fix The sponsor confirmed this issue will not be fixed labels Aug 7, 2023
@0xshinobii
Copy link

This issue has more chances of occurrence when there are volatile assets as collateral. As we are launching with single collateral (USDC) initially, we'll fix this later.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Escalation Resolved This issue's escalations have been approved/rejected Medium A valid Medium severity issue Reward A payout will be made for this issue Sponsor Confirmed The sponsor acknowledged this issue is valid Won't Fix The sponsor confirmed this issue will not be fixed
Projects
None yet
Development

No branches or pull requests

6 participants