Open hats-bug-reporter[bot] opened 6 months ago
The variable is named HUNDRED because it represents 100% The depeg percentage is defined as 1025. This way the calculation becomes cvxAmount*1025/1000, effectively increasing the amount by 2.5% to check for the correct slippage. If the cvxAmount is 1000, 2.5% depeg slippage would give it 1025. Nothing wrong with the code
Github username: -- Twitter username: -- Submission hash (on-chain): 0xe7417261b7f219e97402d2e9be528c105c2cc24ea745fb41bc49d5a6f3bb746e Severity: high
Description: Description\ The method used for converting CVX tokens to CVGCVX is incorrectly divides
((cvxAmount - feesAmount) * depegPercentage)
with 1000 ( THOUSAND) instead of 100 ( HUNDRED)although the constant name is hundred but the value is used is 1000
which leaves this calculation to be always incorrect when
((cvxAmount - feesAmount) * depegPercentage)/100
is supposed to be greater than or equal to left side of the equation_curvePool.get_dy(0, 1, cvxAmount)
this will lead to incorrect calculations and potentially and potentially minting and exchanging incorrect amount of tokwns .
Attack Scenario Whenever someone initiates the deposit transaction inside
CvgCvxStakingPositionService.sol
, the deposit function callsthe conversion from the target function will be incorrect minting more or less CVX1 than intended . This issue escalates when the incorrect amount of assets is exchanged through curve pools
This can also lead to Denial of service of deposit and other functionalities relying on this function due to incorrect parameters [assed for curve pool exchange function and the pool won't have enough funds and rhe transaction might revert in most cases
Attachments
Proof of Concept (PoC) File Please check the detail section
Revised Code File (Optional) modify HUNDRED variable as follows
/// @dev internal constant used for divisions uint256 internal constant HUNDRED = 100;