prePO contest - csanuragjain's results

Gain exposure to pre-IPO companies & pre-token projects.

General Information

Platform: Code4rena

Start Date: 17/03/2022

Pot Size: $30,000 USDC

Total HM: 8

Participants: 43

Period: 3 days

Judge: gzeon

Total Solo HM: 5

Id: 100

League: ETH

prePO

Findings Distribution

Researcher Performance

Rank: 5/43

Findings: 2

Award: $2,122.73

🌟 Selected for report: 1

🚀 Solo Findings: 1

Findings Information

🌟 Selected for report: csanuragjain

Labels

bug
2 (Med Risk)
sponsor confirmed

Awards

2021.4346 USDC - $2,021.43

External Links

Lines of code

https://github.com/code-423n4/2022-03-prepo/blob/main/contracts/core/PrePOMarketFactory.sol#L42

Vulnerability details

Impacted Function:

createMarket

Description:

  1. Owner calls createMarket with _tokenNameSuffix S1 and _tokenSymbolSuffix S2 which creates a new market M1 with _deployedMarkets[_salt] pointing to M1. Here salt can be S which is computed using _tokenNameSuffix and _tokenSymbolSuffix
  2. This market is now being used
  3. After some time owner again mistakenly calls createMarket with _tokenNameSuffix S1 and _tokenSymbolSuffix S2
  4. Instead of returning error mentioning that this name and symbol already exists, new market gets created. The problem here is that salt which is computed using _tokenNameSuffix and _tokenSymbolSuffix will again come as S (as in step 1) which means _deployedMarkets[_salt] will now get updated to M2. This means reference to M1 is gone

Recommendation:

Add below check:

require(_deployedMarkets[_salt]==address(0), "Market already exists");

#0 - ramenforbreakfast

2022-03-22T21:44:53Z

This is a valid submission, and since this would overwrite the existing mapping within PrePOMarketFactory, I think it is fair for this to remain as medium severity.

#1 - gzeoneth

2022-04-03T13:28:35Z

Agree with sponsor

Awards

101.302 USDC - $101.30

Labels

bug
QA (Quality Assurance)

External Links

Deposit can surpass Max Cap

https://github.com/code-423n4/2022-03-prepo/blob/main/contracts/core/CollateralDepositRecord.sol#L67 https://github.com/code-423n4/2022-03-prepo/blob/main/contracts/core/CollateralDepositRecord.sol#L58

Function : setAccountDepositCap/setGlobalDepositCap

Problem: The deposits could surpass the max cap in case either setAccountDepositCap or setGlobalDepositCap is called with lower value than old one

Recommendation: Add a check on setGlobalDepositCap to see require(_globalDepositCap < _newGlobalDepositCap && _newGlobalDepositCap!=0) otherwise the existing deposit could already be surpassing _newGlobalDepositCap. Similarly add check on setAccountDepositCap to verify require(_accountDepositCap < _newAccountDepositCap && _newAccountDepositCap!=0)

No way to unblock accounts:

https://github.com/code-423n4/2022-03-prepo/blob/main/contracts/core/AccountAccessController.sol#L50

Function: blockAccounts

Problem: Once account is Blocked, there is no way to unblock it until and unless you call clearBlockedAccounts function which increments _blockedAccountsIndex. But this will unblock all accounts and not just the one we wished to unblock

Recommendation: Add a function which allows to unblock an account

_blockedAccounts[_blockedAccountsIndex][_accounts[_i]] = false;

Zero address check missing

https://github.com/code-423n4/2022-03-prepo/blob/main/contracts/core/AccountAccessController.sol#L95

Function : setRoot

Description: Zero address checks on _newRoot variable is missing.

Recommendation: Consider adding require(_newRoot != address(0), "Invalid root");

#0 - ramenforbreakfast

2022-03-22T21:41:58Z

No way to unblock accounts, I consider this to be a valid low-severity issue that needs to be amended. Currently the AccountAccessController can't individually unblock accounts without resetting the entire blocklist. This was not intentional.

Deposit can surpass Max Cap This is not an issue and is valid behavior. If the deposit cap has been changed to a value below the current deposits in the vault, it is acceptable to us that deposits will simply be blocked until the vault's deposits falls below the new cap. We should improve our documentation to note this.

Zero address check missing This is not an issue. If a root is not set, the proof verifier will simply fail. This does not result in exploitable behavior to our knowledge.

I consider this to be a valid low-severity submission because of No way to unblock accounts

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