Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple mints can brick any form of salesOption 3 mintings #380

Open
c4-submissions opened this issue Nov 6, 2023 · 7 comments
Open

Multiple mints can brick any form of salesOption 3 mintings #380

c4-submissions opened this issue Nov 6, 2023 · 7 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working edited-by-warden H-04 primary issue Highest quality submission among a set of duplicates satisfactory satisfies C4 submission criteria; eligible for awards selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") sufficient quality report This report is of sufficient quality upgraded by judge Original issue severity upgraded from QA/Gas by judge

Comments

@c4-submissions
Copy link
Contributor

c4-submissions commented Nov 6, 2023

Lines of code

https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/MinterContract.sol#L252

Vulnerability details

Impact

As explained by the sponsor, some collections might want to conduct multiple mints on different days. However, due to the way salesOption 3 works, these multiple mints might encounter issues.

Proof of Concept

A collection has completed its first mint, where it minted 500 NFTs. However, the collection consists of 1000 NFTs, so the owner plans to schedule another mint, this time using sales option 3.

Values
allowlistStartTime 4 PM
allowlistEndTime 7 PM
publicStartTime 7 PM
publicEndTime 1 day after public start
timePeriod 1 min

The first user's mint will proceed smoothly since timeOfLastMint falls within the previous mint period. However, the second user's mint will fail. The same applies to all other whitelisted users. This issue arises due to the following block:

lastMintDate[col] = collectionPhases[col].allowlistStartTime
                + (collectionPhases[col].timePeriod * (gencore.viewCirSupply(col) - 1));

This calculation extends the allowed time significantly, granting the second minter an allowed time of allowlistStartTime + 1 min * (500-1) = allowlistStartTime + 499 min, which is equivalent to 8 hours and 19 minutes after allowlistStartTime. This enables the second user to mint at 12:19 AM, long after the whitelist has ended and in the middle of the public sale. And if anyone tries to mint his call will revert with underflow error, as timeOfLastMint > block.timestamp.

uint256 tDiff = (block.timestamp - timeOfLastMint) / collectionPhases[col].timePeriod;

It's worth noting that some collections may disrupt the whitelist, while others could brick the entire mint process, especially if there are more minted NFTs or a longer minting period.

POC

Gits - https://gist.github.com/0x3b33/677f86f30603dfa213541cf764bbc0e8
Add to remappings - contracts/=smart-contracts/
Run it with forge test --match-test test_multipleMints --lib-paths ../smart-contracts

Tools Used

Manual review.

Recommended Mitigation Steps

For this fix I am unable to give any suggestion as big parts of the protocol need to be re-done. I can only point out the root cause of the problem, which is (gencore.viewCirSupply(col) - 1) in the snippet below.

lastMintDate[col] = collectionPhases[col].allowlistStartTime + (collectionPhases[col].timePeriod * (gencore.viewCirSupply(col) - 1));

Assessed type

Error

@c4-submissions c4-submissions added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Nov 6, 2023
c4-submissions added a commit that referenced this issue Nov 6, 2023
@c4-pre-sort c4-pre-sort added the sufficient quality report This report is of sufficient quality label Nov 20, 2023
@c4-pre-sort
Copy link

141345 marked the issue as sufficient quality report

@c4-sponsor
Copy link

a2rocket (sponsor) confirmed

@c4-sponsor c4-sponsor added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Nov 23, 2023
@c4-judge c4-judge closed this as completed Dec 5, 2023
@c4-judge
Copy link

c4-judge commented Dec 5, 2023

alex-ppg marked the issue as duplicate of #2012

@c4-judge c4-judge reopened this Dec 7, 2023
@c4-judge c4-judge added primary issue Highest quality submission among a set of duplicates selected for report This submission will be included/highlighted in the audit report labels Dec 7, 2023
@c4-judge
Copy link

c4-judge commented Dec 7, 2023

alex-ppg marked the issue as selected for report

@alex-ppg
Copy link

alex-ppg commented Dec 7, 2023

The Warden's submission was selected as the best given that it illustrates the problem by citing the relevant documentation of the project, contains a valid PoC, and acknowledges the difficulty in rectifying this issue. While the submission has under-estimated the issue's severity, the relevant high-severity issues (#2012, #1123, #939, #632, #631, #89) were not of sufficient quality and the best candidate (#1123) minimizes the issue's applicability and does not advise a proper recommendation either.

To alleviate the issue, the Sponsor is advised to implement a "start date" for the periodic sales that is reconfigured whenever a periodic sale is re-instated. This would permit the lastMintDate calculations to "restart" the date from which periodic sale allowances should be tracked and also allow the code to snapshot the circulating supply at the time the first periodic sale occurs of each independent periodic sale phase. As the Warden correctly assessed, a viable solution to this vulnerability is difficult to implement.

@c4-judge
Copy link

c4-judge commented Dec 7, 2023

alex-ppg marked the issue as satisfactory

@c4-judge c4-judge added satisfactory satisfies C4 submission criteria; eligible for awards 3 (High Risk) Assets can be stolen/lost/compromised directly upgraded by judge Original issue severity upgraded from QA/Gas by judge and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Dec 7, 2023
@c4-judge
Copy link

c4-judge commented Dec 7, 2023

alex-ppg changed the severity to 3 (High Risk)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working edited-by-warden H-04 primary issue Highest quality submission among a set of duplicates satisfactory satisfies C4 submission criteria; eligible for awards selected for report This submission will be included/highlighted in the audit report sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") sufficient quality report This report is of sufficient quality upgraded by judge Original issue severity upgraded from QA/Gas by judge
Projects
None yet
Development

No branches or pull requests

7 participants