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

_handleOpenFees returns an incorrect value for _feePaid. This directly impacts margin calculations #367

Open
code423n4 opened this issue Dec 16, 2022 · 9 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 downgraded by judge Judge downgraded the risk level of this issue M-11 primary issue Highest quality submission among a set of duplicates satisfactory satisfies C4 submission criteria; eligible for awards selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/Trading.sol#L178
https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/Trading.sol#L734

Vulnerability details

Impact

Formula for fee paid in Line 734 is incorrect leading to incorrect margin calculations. Since this directly impacts the trader margin and associated fee calculations, I've marked as HIGH risk

On initiating a market order, Margin is adjusted for the fees that is charged by protocol. This adjustment is in Line 178 of Trading. Fees computed by _handleOpenFees is deducted from Initial margin posted by user.

formula misses to account the 2*referralFee component while calculaing _feePaid

Proof of Concept

Note that _feePaid as per formula in Line 734 is the sum of _daoFeesPaid', and sum of burnerFee&botFee. _daoFeesPaidis calculated from_fees.daoFeeswhich itself is calculated by subtracting2*referralFeeandbotFee`.

So when we add back burnerFee and botFee to _feePaid, we are missing to add back the 2*referralFee which was earlier excluded when calculating _daoFeesPaid. While botFee is added back correctly, same adjustment is not being done viz-a-viz referral fee.

This results in under calculating the _feePaid and impacts the rewards paid to the protocol NFT holders.

Tools Used

Recommended Mitigation Steps

Suggest replacing the formula in line 734 with below (adding back _fees.referralFees*2)

            _feePaid =
                _positionSize
                * (_fees.burnFees + _fees.botFees + _fees.referralFees*2 ) 
                / DIVISION_CONSTANT // divide by 100%
                + _daoFeesPaid;
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Dec 16, 2022
code423n4 added a commit that referenced this issue Dec 16, 2022
@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as duplicate of #476

@c4-judge c4-judge added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Jan 16, 2023
@c4-judge
Copy link
Contributor

GalloDaSballo changed the severity to 2 (Med Risk)

@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
@c4-judge c4-judge reopened this Jan 30, 2023
@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as not a duplicate

@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as primary issue

@c4-judge
Copy link
Contributor

GalloDaSballo marked the issue as selected for report

@GalloDaSballo
Copy link

The warden has shown a mistake in how fees are calculated, the impact will cause a loss of yield to the protocol, however no convincing argument was made as to how this can cause a loss to depositors or users (loss of principal), for this reason, I believe Medium Severity to be the most appropriate

@C4-Staff C4-Staff added the M-11 label Jan 31, 2023
@GainsGoblin
Copy link

Mitigation: code-423n4/2022-12-tigris#2 (comment)

@c4-sponsor
Copy link

GainsGoblin marked the issue as sponsor confirmed

@c4-sponsor c4-sponsor added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Feb 13, 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 downgraded by judge Judge downgraded the risk level of this issue M-11 primary issue Highest quality submission among a set of duplicates satisfactory satisfies C4 submission criteria; eligible for awards selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

6 participants