Open Dollar - bitsurfer's results

A floating $1.00 pegged stablecoin backed by Liquid Staking Tokens with NFT controlled vaults.

General Information

Platform: Code4rena

Start Date: 18/10/2023

Pot Size: $36,500 USDC

Total HM: 17

Participants: 77

Period: 7 days

Judge: MiloTruck

Total Solo HM: 5

Id: 297

League: ETH

Open Dollar

Findings Distribution

Researcher Performance

Rank: 30/77

Findings: 2

Award: $144.51

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: falconhoof

Also found by: 0x6d6164616e, Baki, Beosin, Krace, T1MOH, bitsurfer, immeas, pep7siup, tnquanghuy0512, twicek

Labels

bug
3 (High Risk)
partial-50
sufficient quality report
edited-by-warden
duplicate-26

Awards

90.3185 USDC - $90.32

External Links

Lines of code

https://github.com/open-dollar/od-contracts/blob/v1.5.5-audit/src/contracts/AccountingEngine.sol#L199

Vulnerability details

Impact

Wrong surplusTransferPercentage check condition in auctionSurplus. Instead of under 100 WAD, it's currently check if the percentage is under 1 WAD, resulting major issue of not accepting correct surplus transfer percentage in a range of 1 - 100 WAD

Proof of Concept

There is a clear wrong check in AccountingEngine's auctionSurplus function where it should be checking surplusTransferPercentage > ONE_HUNDRED_WAD instead of surplusTransferPercentage > WAD

File: AccountingEngine.sol
199:     if(_params.surplusTransferPercentage > WAD) revert AccEng_surplusTransferPercentOverLimit();

With current code, the surplusTransferPercentage will only accept if the number is under a WAD. Meanwhile there is also check _params.surplusTransferPercentage < ONE_HUNDRED_WAD in Line 213, which is contrary with the line 199, as ONE_HUNDRED_WAD is 100 * WAD.

Tools Used

Manual Analysis

Replace WAD to ONE_HUNDRED_WAD,

if(_params.surplusTransferPercentage > ONE_HUNDRED_WAD) revert AccEng_surplusTransferPercentOverLimit();

Assessed type

Invalid Validation

#0 - c4-pre-sort

2023-10-26T05:30:05Z

raymondfam marked the issue as sufficient quality report

#1 - c4-pre-sort

2023-10-26T05:30:26Z

raymondfam marked the issue as duplicate of #26

#2 - c4-judge

2023-11-03T14:01:38Z

MiloTruck marked the issue as partial-50

#3 - c4-judge

2023-11-03T14:01:45Z

MiloTruck marked the issue as satisfactory

#4 - MiloTruck

2023-11-03T14:01:51Z

Partial credit as this report didn't point out how using ONE_HUNDRED_WAD in percentage calculations results in _amountToSell becoming massively inflated.

#5 - c4-judge

2023-11-03T16:47:53Z

MiloTruck marked the issue as partial-50

Findings Information

🌟 Selected for report: twicek

Also found by: 0xMosh, 0xhacksmithh, Arz, bitsurfer, btk, kutugu, ni8mare, pep7siup, spark, xAriextz

Labels

bug
2 (Med Risk)
low quality report
satisfactory
duplicate-187

Awards

54.1911 USDC - $54.19

External Links

Lines of code

https://github.com/open-dollar/od-contracts/blob/v1.5.5-audit/src/contracts/oracles/UniV3Relayer.sol#L18 https://github.com/open-dollar/od-contracts/blob/v1.5.5-audit/src/contracts/oracles/CamelotRelayer.sol#L20

Vulnerability details

Impact

Wrong addresses for UniV3Relayer and CamelotRelayer (using GOERLI)

Proof of Concept

In UniV3Relayer's _UNI_V3_FACTORY it still use GOERLI instead of UNISWAP_V3_FACTORY. Same case with CamelotRelayer.

In the UniV3Relayer.sol file, on line 18, the constant _UNI_V3_FACTORY is set to GOERLI_UNISWAP_V3_FACTORY. This should likely be replaced with the correct address, which is UNISWAP_V3_FACTORY.

Similarly, in the CamelotRelayer.sol file, on line 20, the constant _CAMELOT_FACTORY is set to GOERLI_CAMELOT_V3_FACTORY. This should be updated to the correct address, which is CAMELOT_V3_FACTORY.

File: UniV3Relayer.sol
16: contract UniV3Relayer is IBaseOracle, IUniV3Relayer {
17:   // --- Registry ---
18:   address internal constant _UNI_V3_FACTORY = GOERLI_UNISWAP_V3_FACTORY;

File: CamelotRelayer.sol
18: contract CamelotRelayer is IBaseOracle, ICamelotRelayer {
19:   // --- Registry ---
20:   address internal constant _CAMELOT_FACTORY = GOERLI_CAMELOT_V3_FACTORY;

Understandably this might be because developer forgot to replace test variable to the intended one, but still this is a medium issue, wrong 'hardcoded' address may resulting a brick of the protocol.

Tools Used

Manual Analysis

Use the correct address of Uniswap and camelot v3 factory

Assessed type

Other

#0 - c4-pre-sort

2023-10-26T05:35:27Z

raymondfam marked the issue as low quality report

#1 - c4-pre-sort

2023-10-26T05:35:51Z

raymondfam marked the issue as duplicate of #119

#2 - c4-judge

2023-11-02T08:46:44Z

MiloTruck marked the issue as satisfactory

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter