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

Wrong minting logic based on total token count across generations #231

Open
howlbot-integration bot opened this issue Aug 9, 2024 · 7 comments
Open
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working H-01 primary issue Highest quality submission among a set of duplicates 🤖_37_group AI based duplicate group recommendation 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

@howlbot-integration
Copy link

Lines of code

https://github.com/code-423n4/2024-07-traitforge/blob/main/contracts/TraitForgeNft/TraitForgeNft.sol#L215

Vulnerability details

https://github.com/code-423n4/2024-07-traitforge/blob/main/contracts/TraitForgeNft/TraitForgeNft.sol#L215

Summary

TraitForgeNft::mintWithBudget function is similar to mintToken, but allows users to mint multiple tokens in a single transaction if they have a budget exceeding the minting price for one token.
However, _tokenIds tracks the total number of tokens ever minted, not just the tokens in the current generation.

Impact

In the current implementation, _tokenIds is used to control the minting process. The check while (budgetLeft >= mintPrice && _tokenIds < maxTokensPerGen) ensures that minting will stop when current generation minted tokens reaches maxTokensPerGen.
Instead of checking the number of tokens minted in the current generation, the function incorrectly checks the total number of tokens minted across all generations (_tokenIds).

Proof of Concept

Here is the current implementation of the mintWithBudget function in the smart contract on line 215:

TraitForgeNft.sol
202:   function mintWithBudget(
203:     bytes32[] calldata proof
204:   )
205:     public
206:     payable
207:     whenNotPaused
208:     nonReentrant
209:     onlyWhitelisted(proof, keccak256(abi.encodePacked(msg.sender)))
210:   {
211:     uint256 mintPrice = calculateMintPrice();
212:     uint256 amountMinted = 0;
213:     uint256 budgetLeft = msg.value;
214: 
215:     while (budgetLeft >= mintPrice && _tokenIds < maxTokensPerGen) { // @audit - _tokenIds counts total tokens minted, not just current generation
216:       _mintInternal(msg.sender, mintPrice);
217:       amountMinted++;
218:       budgetLeft -= mintPrice;
219:       mintPrice = calculateMintPrice();
220:     }
221:     if (budgetLeft > 0) {
222:       (bool refundSuccess, ) = msg.sender.call{ value: budgetLeft }('');
223:       require(refundSuccess, 'Refund failed.');
224:     }
225:   }

The function will not allow minting if _tokenIds is greater than 10,000 which will happen after the 1st generation is fully minted.

Tools Used

Manual Review

Recommended Mitigation Steps

Use generationMintCounts[currentGeneration] instead of _tokenIds.

- while (budgetLeft >= mintPrice && _tokenIds < maxTokensPerGen) {
+ while (budgetLeft >= mintPrice && generationMintCounts[currentGeneration] <= maxTokensPerGen) {

Assessed type

Invalid Validation

@howlbot-integration howlbot-integration bot added 3 (High Risk) Assets can be stolen/lost/compromised directly 🤖_37_group AI based duplicate group recommendation bug Something isn't working primary issue Highest quality submission among a set of duplicates sufficient quality report This report is of sufficient quality labels Aug 9, 2024
howlbot-integration bot added a commit that referenced this issue Aug 9, 2024
@TForge1 TForge1 added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Aug 10, 2024
@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Aug 18, 2024
@c4-judge
Copy link
Contributor

koolexcrypto marked the issue as satisfactory

@c4-judge
Copy link
Contributor

koolexcrypto marked the issue as selected for report

@c4-judge c4-judge added selected for report This submission will be included/highlighted in the audit report 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Aug 19, 2024
@c4-judge
Copy link
Contributor

koolexcrypto changed the severity to 2 (Med Risk)

@c4-judge c4-judge added 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 downgraded by judge Judge downgraded the risk level of this issue labels Aug 19, 2024
@c4-judge
Copy link
Contributor

koolexcrypto changed the severity to 3 (High Risk)

@c4-judge c4-judge removed the 3 (High Risk) Assets can be stolen/lost/compromised directly label Aug 19, 2024
@c4-judge
Copy link
Contributor

koolexcrypto changed the severity to 2 (Med Risk)

@c4-judge c4-judge added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue and removed upgraded by judge Original issue severity upgraded from QA/Gas by judge 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue labels Aug 19, 2024
@c4-judge c4-judge added 3 (High Risk) Assets can be stolen/lost/compromised directly upgraded by judge Original issue severity upgraded from QA/Gas by judge labels Aug 19, 2024
@c4-judge
Copy link
Contributor

koolexcrypto changed the severity to 3 (High Risk)

@AtanasDimulski
Copy link

@koolexcrypto thanks for the swift judging! I have the same finding in my QA report #32 L-01, I guess it has been missed. Can you please make it a duplicate of this issue? Thanks for your time!

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 H-01 primary issue Highest quality submission among a set of duplicates 🤖_37_group AI based duplicate group recommendation 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

4 participants