-
Notifications
You must be signed in to change notification settings - Fork 6
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
InstantManager attempts to redeem BUIDL even if it has enough USDC in the contract #109
Comments
0xRobocop marked the issue as sufficient quality report |
0xRobocop marked the issue as primary issue |
0xRobocop marked the issue as high quality report |
I think there may be something here - can we provide some examples with real numbers? |
cameronclifton (sponsor) acknowledged |
The finding is valid, and the recommended mitigation is very sound, so the sponsor is warmly recommended to consider it. However, for fairness, we'll need to close this issue because the README noted this scenario as a publicly known issue.
Honorable mention to #235 that, too, highlights how the redeem logic is stricter than it could. |
3docSec marked the issue as unsatisfactory: |
cameronclifton (sponsor) confirmed |
We will be addressing this mitigation, I think this is a good finding. |
I'm afraid this statement is too broad, as it encompasses scenarios in which there may not be enough BUIDL tokens to cover redemptions due to normal activity, as well as legit attack cases where BUIDL was removed from the contract by a malicious user. Can we please ask sponsors to clarify what did they mean in the "Known Issues"? It seems unlikely that they would knowingly leave such a vulnerability that can be exploited, like it was shown in this report and it's dupes. Thank you. |
Hi @k4zanmalay we can absolutely have the sponsor clarify. However, clarification should've been done before the contest ended, and made public to all wardens to be considered in judging: we may very well have had other wardens notice this finding, and not report it because they thought it fell under this known issue; considering it valid depending on the sponsor clarifying their intention after the contest would be unfair. |
Hi @3docSec I believe it should be treated as escalation of already known issue, like it's done with findings based on bot reports |
A bot finding typically has a root cause, an impact, and a mitigation that may make it inaccurate. A "known issue" from the sponsor doesn't, so what you say sounds a bit forced. However, I definitely see a margin for improving our judging guidelines, especially on how known issues can be interpreted and to what extent are they open to escalations, like you said, like bot reports are. If you open an issue here (just make sure there isn't one already!) I'll be happy to support it. |
Lines of code
https://github.com/code-423n4/2024-03-ondo-finance/blob/main/contracts/ousg/ousgInstantManager.sol#L426-L448
Vulnerability details
Impact
Redemptions of amounts greater than
minBUIDLRedeemAmount
will revert even if there are enough USDC tokens in the contract to perform a payoff.Proof of Concept
During the redemption, a situation may occur when there are not enough BUIDL tokens in the contract to perform
_redeemBUIDL
, but the USDC balance is greater thanusdcAmountToredeem
. Because we checkusdcAmountToRedeem >= minBUIDLRedeemAmount
beforeusdcAmountToRedeem > usdcBalance
, the contract will attempt to redeem BUIDL tokens every time and fail.A malicious user can exploit this vulnerability and make the contract redeem all it's BUIDL tokens with multiple mint/redeem runs (possibly involving flashloans). As a result, all redemptions with amounts greater than
minBUIDLRedeemAmount
will fail.Tools Used
Manual review
Recommended Mitigation Steps
Consider refactoring the condition statement as follows
Assessed type
Other
The text was updated successfully, but these errors were encountered: