-
Notifications
You must be signed in to change notification settings - Fork 3
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
Vulnerability in burnToMint function allowing double use of NFT #1597
Comments
141345 marked the issue as primary issue |
Minter.burnToMint()
the attacker can sell the burn collection's NFT right before it's burned
#571
the proposed mitigation is not fully corrected as you need to store the current owner of the token before burning it and use that into safeMint. If you do it like its proposed the safeMint will not be able to send the token. |
a2rocket (sponsor) confirmed |
141345 marked the issue as sufficient quality report |
141345 marked the issue as duplicate of #1742 |
alex-ppg marked the issue as not a duplicate |
alex-ppg marked the issue as primary issue |
The Warden has showcased that due to the absence of the Checks-Effects-Interactions pattern, it is possible to utilize an NFT to-be-burned (f.e. to sell it) before the actual burning operation is executed. While the recommended alleviation does not work as expected per the Sponsor's comments, the submission is valid as it can cause the recipient of an NFT (if an open sale exists) to lose their value and not acquire any NFT. I will downgrade this to a medium severity vulnerability per the judging guidelines as the only loss-of-value is a hypothetical value of an external protocol (i.e. trading one) rather than the NextGen system. |
alex-ppg changed the severity to 2 (Med Risk) |
alex-ppg marked the issue as selected for report |
alex-ppg marked the issue as satisfactory |
The Warden's submission was selected as the best due to a correct title, cleaner & concise representation throughout, and illustrative recommended mitigation. |
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/58090c9fbc036c06bbaa9600ec326034f2181a17/hardhat/smart-contracts/NextGenCore.sol#L213-L223
https://github.com/code-423n4/2023-10-nextgen/blob/58090c9fbc036c06bbaa9600ec326034f2181a17/hardhat/smart-contracts/NextGenCore.sol#L227-L232
Vulnerability details
Impact
The current implementation of the
burnToMint
function in theNextGenCore.sol
smart contract permits a contract holder to both burn and sell the same NFT, effectively exploiting it to mint a new NFT. This leads to potential fraudulent activities when trading the NFT.Proof of Concept
The vulnerability stems from the order of operations in the
burnToMint
function. Currently, a new token is minted (_mintProcessing
) before the existing token is burned (_burn
). This sequence of operations opens a window for exploitation:https://github.com/code-423n4/2023-10-nextgen/blob/58090c9fbc036c06bbaa9600ec326034f2181a17/hardhat/smart-contracts/NextGenCore.sol#L213-L223
The
_mintProcessing
function calls_safeMint
, which in turn can trigger arbitrary code execution if the recipient is a contract. This allows for manipulation such as transferring the NFT (set to be burned) to another user before the burn occurs:https://github.com/code-423n4/2023-10-nextgen/blob/58090c9fbc036c06bbaa9600ec326034f2181a17/hardhat/smart-contracts/NextGenCore.sol#L227-L232
A malicious actor can exploit this by listing the NFT for sale. When there is a buy offer, the malicious contract can call
burnToMint
to receive the new NFT and simultaneously accept an offer to buy the original NFT, resulting in the original NFT being burned but still sold, effectively duping the buyer.In this POC scenario, there are two collection 1 and 2. The admin is set so that users can burn token in collection 1 to mint token in collection 2.
10000000000
of collection 1, it lists the token10000000000
in the marketplace.addr3
offer to buy the token10000000000
from the malicious contract.burnToMint
, stimulously receive token20000000000
from collection 2 and accept offer to buy10000000000
fromaddr3
.10000000000
is burnt andaddr3
receive nothing. The malicious contract receives both token20000000000
fromburnToMint
and proceed from the sales of token10000000000
.POC:
Tools Used
Manual
Recommended Mitigation Steps
The order of operations in the
burnToMint
function should be revised to ensure that the token is burned before a new one is minted:Assessed type
Reentrancy
The text was updated successfully, but these errors were encountered: