Munchables - mitko1111's results

A web3 point farming game in which Keepers nurture creatures to help them evolve, deploying strategies to earn them rewards in competition with other players.

General Information

Platform: Code4rena

Start Date: 22/05/2024

Pot Size: $20,000 USDC

Total HM: 6

Participants: 126

Period: 5 days

Judge: 0xsomeone

Total Solo HM: 1

Id: 379

League: ETH

Munchables

Findings Distribution

Researcher Performance

Rank: 48/126

Findings: 2

Award: $0.02

🌟 Selected for report: 0

🚀 Solo Findings: 0

Lines of code

https://github.com/code-423n4/2024-05-munchables/blob/57dff486c3cd905f21b330c2157fe23da2a4807d/src/managers/LockManager.sol#L245-L272 https://github.com/code-423n4/2024-05-munchables/blob/57dff486c3cd905f21b330c2157fe23da2a4807d/src/managers/LockManager.sol#L381-L385

Vulnerability details

Impact

When we call LockManager::setLockDuration() to set the lock duration for a player's tokens there is a check we are not setting the lock time before current unlock time but despite that lock time can be before current unlock time because when we update the current unlocktime we use the last lock time timestamp instead of block.timestamp

Proof of Concept

Here is an example with just numbers

We are locking a token and setting last lock time equal to 10 (It is not time just a number for the example).

Last lock time = 10 Unlock time = 50

We are calling setLockDuration(duration = 35)

Current time = 20

In the check we have 35 + 20 = 55 > 50 => we dont set the lock time before the current unlock time, but when we set the new unlock time we have:

10 + 35 = 45 => new unlock time is 45 < 50

Tools Used

Mannual review


lockedTokens[msg.sender][tokenContract].unlockTime = block.timestamp + uint32(_duration);


Assessed type

Error

#1 - CloudEllie

2024-05-31T16:55:05Z

Changing primary to #89 per Validators' recommendation

#2 - c4-judge

2024-06-05T12:52:22Z

alex-ppg marked the issue as partial-75

Lines of code

https://github.com/code-423n4/2024-05-munchables/blob/57dff486c3cd905f21b330c2157fe23da2a4807d/src/managers/LockManager.sol#L177-L207

Vulnerability details

Impact

If a role approves a USD price proposal and then tries to disapprove it, an exception will be thrown. However, if a user first disapproves a proposal, they are still allowed to approve it afterward. This means a proposal can be approved and disapproved at the same time by the same role.

Proof of Concept

Tools Used

Add a check if a role has already disapproved the proposal in approveUSDPrice()

Assessed type

Invalid Validation

#0 - c4-judge

2024-06-05T12:42:47Z

alex-ppg 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