Ondo Finance - Bigsam's results

0xRobocop marked the issue as insufficient quality report

0xRobocop marked the issue as duplicate of #267

0xRobocop marked the issue as not a duplicate

0xRobocop marked the issue as duplicate of #179

3docSec marked the issue as unsatisfactory: Insufficient proof

Thank you for judging @3docSec,

I believe this issue might be on course, This issue is completely different from the main issue #179, it outlines a possible denial of service even if the protocol has enough funds. The judge can decide to have a second look, it looks similar to #142 and an issue that was acknowledged by sponsor #109. EVEN if the above issues mitigations are followed the issue stated here will still be present. This finding is not THE SAME as #109 and #142 and is completely different from the Readme. According to the warden, there is a possible denial of service even if we have enough buidl and also have redeemable usdc but redemption will still fail. Because the protocol is checking build>=minimum(250k), they should be checking buidl balance>=buidl to redeem (which can be above 250k) since it is already a fact that we cannot redeem less than 250k. The above MITIGATION allows for the possibility to pay users when we have enough considering the different possibilities.

According to the doc

We are aware that if all BUIDL has been redeemed from our contract, we would not be able to provide instant redemptions for OUSG or rOUSG. We are also aware that there may be some USDC leftover in the contract that wouldn't be redeemable in this scenario.

From the DOC statement nothing points to the protocol not having enough buidl to be redeemed in this findings because we have more than the minimum and nothing points to an unredeemable usdc and yet the USER will be denied.

Scenario 1: the revert will happen only if the redeemer sends back fewer USDC tokens than BUIDL sent, which is precisely #175 Scenario 2: this looks really like #109, so I'll move this finding there.

However:

We are aware that if all BUIDL has been redeemed from our contract [...] there may be some USDC leftover in the contract that wouldn't be redeemable in this scenario.

is very much like:

even though approve is given to the buidl to redeem the transaction will fail due to insufficient balance [...] the user is not paid even though we have enough usdc

3docSec marked the issue as not a duplicate

3docSec changed the severity to QA (Quality Assurance)

3docSec marked the issue as grade-b

This previously downgraded issue has been upgraded by 3docSec

3docSec marked the issue as duplicate of #109

3docSec marked the issue as unsatisfactory: Out of scope

Thanks once again for judging @3docSec,

i believe this issue is a duplicate of #306, both speak on the redemption function unlike #109 and their mitigation is the same.

@3docSec still awaiting your response.

like i have explained initially, a complete review of this shows that it is a duplicate of #306 . same impact,function and mitigation.

To address this issue, the OUSG Instant Redemption Manager contract should implement a mechanism to ensure that redemption requests do not exceed the available BUIDL balance held by the manager contract. This can be achieved by incorporating proper checks and balances in the redemption process, such as verifying the BUIDL balance before processing redemption requests and adjusting the redemption amount accordingly. Additionally, consider an redeem implementation that concatenate the balance of remaining USDC amount with the BUIDL redeemed balance if the corresponding USDC amount or redeem amount of OUSG is more than minBUIDLRedeemAmount.

mitigation from #306 a review shows total similarity. and from your initial comment on both issue it sounds like but it is not, has confirmed by the sponsor in 306.

Hi @lanrebayode I reviewed attentively your claim, and no, scenario 2 is not #306.

The finding in 306 points out a scenario where the contract's BUILD balance is higher than minBUIDLRedeemAmount, so this specific part of your PoC:

failed check

 require(
     buidl.balanceOf(address(this)) >= minBUIDLRedeemAmount,
     "OUSGInstantManager::_redeemBUIDL: Insufficient BUIDL balance"
   );

makes it unequivocally clear that the root cause pointed out here is not the same as #306, and that this finding falls in the same out of scope criteria as #109 :

We are aware that if all BUIDL has been redeemed from our contract, we would not be able to provide instant redemptions for OUSG or rOUSG. We are also aware that there may be some USDC leftover in the contract that wouldn't be redeemable in this scenario.

@3docSec Based on the scenario you mention line 2 of scenario 2 as stated by the warden

If the contract has enough enough Usdc or buidl+Usdc, and buidl balance of the contract is more than the minimum to redeem but the transaction still fails which is clearly the same as #306

also look at th wardens mitigation

else if (TotalBalance >= buidlAmountToRedeem && Buidlbal < buidlAmountToRedeem && Buidlbal >= minBUIDLRedeemAmount) { buidl.approve(address(buidlRedeemer), Buidlbal); buidlRedeemer.redeem(Buidlbal); require( usdc.balanceOf(address(this)) == usdcBalanceBefore + Buidlbal, "OUSGInstantManager::_redeemBUIDL: BUIDL:USDC not 1:1" ); Buidlbal+= buidlAmountToRedeem - Buidlbal;// increment balance of contract with the difference

this clearly covers all the stated conditions with a well thought out mitigation and is completely the same has #306.

Hi, you are right, the second scenario explicitly mentions that the contract has more than the minimum, the sum of usdc + buidl balance is enough, and the transaction fails. The mitigation also makes sense in context with #306.

I am duping this to #306, but in your further contributions you really should improve the clarity of your reports:

• if you have two root causes (scenario 1 and scenario 2), make 2 separate findings
• proofread your sentences, some are really hard to follow
• verify the accuracy of your technical statements, or even better, include a coded PoC.

Why the last point? The below statement is NOT where your scenario would fail because of the assumption you made and buidl balance of the contract is more than the minimum to redeem, and this incorrect assumption was a pretty convincing argument for not giving credit.

failed check

require(
     buidl.balanceOf(address(this)) >= minBUIDLRedeemAmount,
     "OUSGInstantManager::_redeemBUIDL: Insufficient BUIDL balance"
   );

3docSec marked the issue as not a duplicate

3docSec marked the issue as duplicate of #306

3docSec marked the issue as satisfactory