Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Centralization allows owner to withhold user payouts #224

Closed
code423n4 opened this issue Dec 15, 2022 · 6 comments
Closed

Centralization allows owner to withhold user payouts #224

code423n4 opened this issue Dec 15, 2022 · 6 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) duplicate-377 satisfactory satisfies C4 submission criteria; eligible for awards sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-12-tigris/blob/main/contracts/Trading.sol#L926-L933

Vulnerability details

Impact

The owner of the contract could set the maxWinPercent state variable in the Trading contract to something like 0.000001%, which will withhold basically all user deposited funds (for open market orders) inside the StableVault contract. See here for the usage of maxWinPercent.

The impact of this is reduced due to two circumstances:

  1. The owner is a multisig Gnosis wallet
  2. There isn't a way for the owner to rug the StableVault contract (as far as I can see)

Regardless, since the payout includes the initial amount the user invested into the order, the owner is able to basically trap user funds with an extremely low maxWinPercent. The impact is the same if the multisig wallet is somehow compromised.

Proof of Concept

The owner would simply need to call setMaxWinPercent() (See here) with a value of 1. Closing any market orders after that would return a negligible amount of the initially deposited user funds, no matter whether the user is supposed to have made a profit or a loss.

Let me know if a PoC for this is actually necessary.

I mentioned above that the payout includes the initial amount that the user invested into the order. We know this because the order of function calls required to get to the usage of maxWinPercent (linked in the "Impact" section above) is (and this is just one example):

  1. initiateCloseOrder()
  2. _closePosition().

Inside _closePosition(), the code uses tradingExtension._closePosition() to get the payout. See here.

Looking at TradingExtension, this function will use the TradingLibrary contract's pnl() function to calculate the payout:

Looking at the pnl() function, it uses the order's position size, opening price, margin, and the current price to calculate the payout. This means it includes the entire amount that the user deposited for the order.

Tools Used

N/A

Recommended Mitigation Steps

Set a minimum limit for the maxWinPercent in setMaxWinPercent().

Better yet, remove this function. I don't see a purpose to this function. Why would you want to prevent users from earning their winnings? Trust in the platform itself is lessened with a function like this in the contract, even with a minimum limit set.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Dec 15, 2022
code423n4 added a commit that referenced this issue Dec 15, 2022
@TriHaz
Copy link

TriHaz commented Jan 3, 2023

As mentioned in other centralization issues, we are aware of the risk and contracts owner will be a multi-sig treasury for now.

@c4-sponsor
Copy link

TriHaz marked the issue as sponsor acknowledged

@c4-sponsor c4-sponsor added the sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons label Jan 3, 2023
@c4-sponsor
Copy link

TriHaz marked the issue as disagree with severity

@c4-sponsor c4-sponsor added the disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) label Jan 3, 2023
@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as duplicate of #377

@GalloDaSballo
Copy link

Admin privilege denial of yield

@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Jan 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working disagree with severity Sponsor confirms validity, but disagrees with warden’s risk assessment (sponsor explain in comments) duplicate-377 satisfactory satisfies C4 submission criteria; eligible for awards sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Projects
None yet
Development

No branches or pull requests

5 participants