Popcorn contest - mert_eren's results

A multi-chain regenerative yield-optimizing protocol.

General Information

Platform: Code4rena

Start Date: 31/01/2023

Pot Size: $90,500 USDC

Total HM: 47

Participants: 169

Period: 7 days

Judge: LSDan

Total Solo HM: 9

Id: 211

League: ETH

Popcorn

Findings Distribution

Researcher Performance

Rank: 60/169

Findings: 3

Award: $170.01

🌟 Selected for report: 0

πŸš€ Solo Findings: 0

Findings Information

🌟 Selected for report: waldenyan20

Also found by: 0xRobocop, KIntern_NA, Ruhum, cccz, hansfriese, mert_eren, minhtrng, peanuts

Labels

bug
3 (High Risk)
disagree with severity
partial-25
sponsor confirmed
duplicate-424

Awards

46.2505 USDC - $46.25

External Links

Lines of code

https://github.com/code-423n4/2023-01-popcorn/blob/d95fc31449c260901811196d617366d6352258cd/src/utils/MultiRewardStaking.sol#L305-L315

Vulnerability details

Impact

if changeRewardSpeed used after rewardTime end and there is still remaining token which is unclaimed, protocol calculate endRewardtime with these tokens and other users can claim other users' unclaimed token.

Proof of Concept

https://imgur.com/a/AMOKJ8A there is a picture show the scenerio. changeRewardSpeed give token balance of this contract instead of remaining token which cannot be taken by anyone with cliamRewards. Because of that if changeRewardSpeed is used unclaimed tokens take into account as not distrubuted yet and distrubutes other people. So users can takeother people's money and even worse some people cannot take any of their reward because they try to withdraw more than contract has.

Tools Used

Instead of calculate balance of contract keep record and use undistrubuted rewards in calcRewardEnd.

#0 - c4-judge

2023-02-16T03:56:26Z

dmvt marked the issue as duplicate of #156

#1 - c4-sponsor

2023-02-18T11:59:05Z

RedVeil marked the issue as disagree with severity

#2 - c4-sponsor

2023-02-18T11:59:08Z

RedVeil marked the issue as sponsor confirmed

#3 - c4-judge

2023-02-23T15:34:12Z

dmvt marked the issue as not a duplicate

#4 - c4-judge

2023-02-23T15:34:26Z

dmvt marked the issue as duplicate of #191

#5 - c4-judge

2023-02-23T23:02:38Z

dmvt marked the issue as partial-25

Awards

1.1529 USDC - $1.15

Labels

bug
3 (High Risk)
partial-25
sponsor confirmed
duplicate-402

External Links

Lines of code

https://github.com/code-423n4/2023-01-popcorn/blob/d95fc31449c260901811196d617366d6352258cd/src/utils/MultiRewardStaking.sol#L170-L185

Vulnerability details

Impact

ClaimReward function was not created in check effect interaction critera so there is possible reentrancy attack when reward token is erc777.

Proof of Concept

There is just one way for accruedRewards change to 0 and it is after transfer of tokens. If erc777 token will be transfered, a malicious user can use claimRewards before accruedRewards of user change, so malicious user can reenter function and steal funds. (there is no update in accruedRewards map in another sub function in claimReward except in accuedUser. However in accruedUser just increase if time passed.So when reenter, due to there is no timePassed, accruedRewards just increase 0 in accruedUser and dont update in any ways.Because of that every reentrancy withdraw same amount of first accruedRewards amount.

Tools Used

Change balance of accruedRewards map of user before transfer token.

#0 - c4-judge

2023-02-16T07:39:29Z

dmvt marked the issue as duplicate of #54

#1 - c4-sponsor

2023-02-18T12:11:04Z

RedVeil marked the issue as sponsor confirmed

#2 - c4-judge

2023-02-23T00:59:26Z

dmvt marked the issue as partial-25

Findings Information

🌟 Selected for report: ustas

Also found by: 0xRobocop, Ada, bin2chen, georgits, gjaldon, hashminer0725, ktg, mert_eren, okkothejawa, pwnforce

Labels

bug
3 (High Risk)
disagree with severity
satisfactory
sponsor confirmed
edited-by-warden
duplicate-45

Awards

122.6059 USDC - $122.61

External Links

Lines of code

https://github.com/code-423n4/2023-01-popcorn/blob/d95fc31449c260901811196d617366d6352258cd/src/vault/VaultController.sol#L667-L670

Vulnerability details

Impact

_verifyCreatorOrOwner function should pass when msg.sender should be creator or owner. However it is pass only if msg.sender creator of vault and contract owner at the same time.

Proof of Concept

_verifyCreatorOrOwner function has if condition and if this condition true function will revert. So this condition should be false for passing. Condition says "msg.sender != metadata.creator || msg.sender != owner" so if msg.sender is creator but not owner, than condition became true because msg.sender!=owner. So creator which is not owner or owner which is not creator of vault cant use functions which checked with _verifyCreatorOrOwner function. However,they should can use these functions. The test is here: https://imgur.com/a/qbBKhCc

Tools Used

Use && instead of ||.

#0 - c4-judge

2023-02-16T07:24:28Z

dmvt marked the issue as duplicate of #45

#1 - c4-sponsor

2023-02-18T12:08:25Z

RedVeil marked the issue as disagree with severity

#2 - c4-sponsor

2023-02-18T12:08:38Z

RedVeil marked the issue as sponsor confirmed

#3 - c4-judge

2023-02-23T00:18:21Z

dmvt 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