Open code423n4 opened 1 year ago
0xSorryNotSorry marked the issue as high quality report
0xSorryNotSorry marked the issue as duplicate of #698
toshiSat marked the issue as sponsor disputed
This is as intented
Picodes marked the issue as not a duplicate
Picodes changed the severity to QA (Quality Assurance)
Briefly checking the code of sfrxETH and wstETH I don't see how the price could change between the 2 calls, and this isn't demonstrated in this report.
This function may return a different outcome
This would need to be demonstrated or at least we should have some hypothetical scenario for the severity to be Med
Lines of code
https://github.com/code-423n4/2023-03-asymmetry/blob/main/contracts/SafEth/SafEth.sol#L63-L101
Vulnerability details
Impact
Based on the description in the poc section, we can see that the staking function calculates the derivatives "underlyingValue" and "derivativeReceivedEthValue" based on two different values of "ethPerDerivative". This both local amounts are later used for the calculation of the amount of tokens minted to the user.
Proof of Concept
The problem occurs mainly for the derivatives SfrxEth and WstEth, if we look on the staking function below, we can see that the underlying value is calculated based on the function "ethPerDerivative", which returns the eth per derivative value.
The preDepositPrice is calculated based on this underlying value, which is later used for the mintAmount calculation. The problem which occurs here is that prior to calculating the "derivativeReceivedEthValue", a different "ethPerDerivative" will be used, as the function first deposits the msg.value to the derivatives, which changes the balances in the pool and therefore a different value might be returned.
Let's look at the SfrxEth derivative first, we can see that the function converts shares of 1e18 to assets. This function may return a different outcome at the end when calculating "derivativeReceivedEthValue" , as depositing funds happens first which will change the balances in the Sfrx contract, therefore the amount returned from the function convertToAssets might also be different.
Same issue occurs for the WstEth derivative as well.
Tools Used
Manual review.
Recommended Mitigation Steps
To simple fix this issue and prevent the use of two different eth per derivative values. We can cache the return value of the function "ethPerDerivative" before the deposit was made. So both "underlyingValue" and "derivativeReceivedEthValue" can be calculated based on the same eth per derivative.