Closed howlbot-integration[bot] closed 4 months ago
Great usage of tooling to show an important invariant of "output amounts should be the same regardless of function parameters used", but the report lacks a proper explanation of the underlying root cause.
Duplicate of #213
I agree with the sponsor. Will apply 75% partial credit.
hansfriese changed the severity to 3 (High Risk)
hansfriese marked the issue as partial-75
hansfriese marked the issue as duplicate of #213
hansfriese marked the issue as duplicate of #288
Lines of code
https://github.com/code-423n4/2024-06-size/blob/8850e25fb088898e9cf86f9be1c401ad155bea86/src/Size.sol#L188-L195 https://github.com/code-423n4/2024-06-size/blob/8850e25fb088898e9cf86f9be1c401ad155bea86/src/libraries/actions/SellCreditMarket.sol#L127-L204
Vulnerability details
Summary
When users buy or sell a credit position, fees are applied based on whether they provide the amount IN or the amount OUT. Depending on which amount is specified, different functions are triggered to calculate these fees and the corresponding amounts.
In some cases, the expected reciprocity between input and output amounts and associated fees is not maintained. For example, when Y amount IN results in X amount OUT with W fees, the reverse scenario where X amount IN does not result in Y amount OUT and W fees introduces discrepancies and inequalities among users.
Description
The issue arises in the
buyCreditMarket
andsellCreditMarket
functions withinsize.sol
. For the sake of clarity, let's focus onsellCreditMarket
.The problem manifests when users attempt to purchase a limit offer using the special ID
RESERVED_ID
. The critical function involved isexecuteSellCreditMarket
:https://github.com/code-423n4/2024-06-size/blob/8850e25fb088898e9cf86f9be1c401ad155bea86/src/Size.sol#L188-L195
https://github.com/code-423n4/2024-06-size/blob/8850e25fb088898e9cf86f9be1c401ad155bea86/src/libraries/actions/SellCreditMarket.sol#L127-L204
In these functions, the calculation of
creditAmountIn
,cashAmountOut
, andfees
differs depending on whetherparams.amount
is considered as the input amount (params.exactAmountIn
==TRUE
) or the output amount (params.exactAmountIn
==FALSE
).This differentiation should maintain consistency in both directions to ensure fairness and equality among users.Assertion
: When a specific amount X is used ascreditAmountIn
resulting incashAmountOut
andfees
withparams.exactAmountIn == TRUE
, the samecreditAmountIn
andfees
should be obtained whenparams.exactAmountIn == FALSE
, and thecashAmountOut
equal the previouscashAmountOut
.POC
To validate the consistency between the
getCashAmountOut
andgetCreditAmountIn
functions, a series of tests were conducted using Echidna. These tests were designed to chain the output of one function as input into the other, ensuring that the initial input value is preserved as the output of the second function.Test Parameters
Each function was parameterized with specific values to ensure comprehensive testing:
Test Cases
Four specific test cases were implemented in
/test/invariants/TargetFunctions.sol
to cover different scenarios with specific input bounds:Echidna Output
The output from Echidna highlighted several failures where the assertions did not hold true, indicating discrepancies between expected and actual results in fees and amounts. This included cases where:
Local reproduction wih foundry
To further validate these findings locally, tests were reproduced using Foundry. Create a file in
test/libraries/
FeesTest.t.sol
and copy paste this in it:Taking example of the last test,
test_inputExactOutputSell2Fees
, run the test with foundry:As observed from Echidna tests, there is a discrepancy in fees:
fees1
is calculated as 950,862.710 USDC andfees2
as 950,849.685 USDC when represented with a decimal precision of 1e6.The difference in fees,
diffFees
, is computed as follows:diffFees = fees1 β fees2 = 950,862.710 β 950,849.685 = 0.013025
This discrepancy in fees is proportional to the value of
params.amount
, increasing linearly with its value.Upon running additional tests, it was noted that:
The specific test cases implemented to verify these scenarios are:
Impact
The discrepancies observed in fees and amounts spanned across different
amount
ranges, impacting various user types. This inconsistency implies that users may receive or pay different amounts for identical transactions, resulting in unequal treatment among users. Specifically:Recommendations
Update the fee calculation logic to ensure consistency across different scenarios, accurately calculating fees and amounts for all transactions.
If this is not feasible, update the documentation accordingly or list this issue under known issues.
Assessed type
Math