-
Notifications
You must be signed in to change notification settings - Fork 1
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
0x73696d616f - Users redeeming early will withdraw Ra
without decreasing the amount locked, which will lead to stolen funds when withdrawing after expiry
#166
Comments
Ra
without decreasing the amount locked, which will lead to stolen funds when withdrawing after expiryRa
without decreasing the amount locked, which will lead to stolen funds when withdrawing after expiry
Escalate It should be dupe of #126 , Even though this report revolves around lvRedeemRaWithCtDs, the root cause concerns incorrect state updates for redemption assets. |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
The fix here is different in both issues, adding #119 uses the same fix for everything, fetching the exchange rate and multiplying/dividing by it. |
But in the end it falls under the same thing "locked/Unlocked accounting" just like multiplying/dividing the exchange rate , isnt that the same thing |
There are multiple ways to do incorrect ra tracking but not taking the exchange rate into account is always the same bug. |
I agree with @SakshamGuruji3. Issues #126, #155, and #166 (this one) all share the same root cause. They should be consolidated into a single issue. |
"Wrong accounting" is not a root cause. The fixes are all different. Both in the code and conceptually. |
The protocol team fixed this issue in the following PRs/commits: |
The argument is still not convincing , first of all 119 has been reported correctly we can not submit 5 vulnerabilities separately for the same root cause (incorrect exchange rate accounting) , secondly the root cause is here the same "not accounting for locked/unlocked RA correctly" and should be grouped together |
The fixes are all different, in the code and conceptually. #126 calls the wrong function, lockUnchecked() instead of lockFrom(). The exchange rate issues are all missing taking into account the exchange rate and the fix is the exact same for all. These 3 mentioned issues have different fixes because we may need to add more or less ra depending on the function (the wrong amount is not always the same) whereas taking into account the exchange rate is a fixed amount and always the same fix. |
From my understanding, reports #126 and #155 lead to a similar impact, but the underlying reason and root causes are different in all situations. I also agree with @0xsimao and @AtanasDimulski that |
Result: |
Escalations have been resolved successfully! Escalation status:
|
0x73696d616f
High
Users redeeming early will withdraw
Ra
without decreasing the amount locked, which will lead to stolen funds when withdrawing after expirySummary
VaultLib::redeemEarly() is called when users redeem early via Vault::redeemEarlyLv(), which allows users to redeem
Lv
forRa
and pay a fee.In the process, the
Vault
burnsCt
andDs
in VaultLib::_redeemCtDsAndSellExcessCt() forRa
, by calling PsmLib::PsmLibrary.lvRedeemRaWithCtDs(). However, it never calls RedemptionAssetManagerLib::decLocked() to decrease the tracked lockedRa
, but theRa
leaves theVault
for the user redeeming.This means that when a new
Ds
is issued in thePsmLib
or users call PsmLib::redeemWithCt(), PsmLib::_separateLiquidity() will be called and it will calculated the exchange rate to withdrawRa
andPa
as if theRa
amount withdrawn earlier was still there. When it calls self.psm.balances.ra.convertAllToFree(), it converts the locked amount to free and assumes these funds are available, when in reality they have been withdrawn earlier. As such, theRa
andPa
checkpoint will be incorrect and users will redeem moreRa
than they should, such that the last users will not be able to withdraw and the first ones will profit.Root Cause
In
PsmLib.sol:125
,self.psm.balances.ra.decLocked(amount);
is not called.Internal pre-conditions
None.
External pre-conditions
None.
Attack Path
Vault::redeemEarlyLv()
orModuleCore::issueNewDs()
is called by the admin.Impact
Users withdraw more funds then they should via
PsmLib::redeemWithCt()
meaning the last users can not withdraw.PoC
PsmLib::lvRedeemRaWithCtDs()
does not reduce the amount ofRa
locked.Mitigation
PsmLib::lvRedeemRaWithCtDs()
must reduce the amount ofRa
locked.The text was updated successfully, but these errors were encountered: