Max allowance restriction can be bypassed both for addresses for WL and public distributions due to reentrancy in mint function #1270
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-1517
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/NextGenCore.sol#L193-L200
https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/NextGenCore.sol#L227-L232
https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/MinterContract.sol#L213-L217
https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/MinterContract.sol#L234-L237
Vulnerability details
Impact
It is possible to bypass max allowance restriction both for WL addresses and public ones. Since getting whitelisted usually is not that easy and it takes time and effort, bypassing allowance restrictions for WL is pretty serious.
Proof of Concept
To mint a token, users would call the
MinterContract.mint()
function. First, it checks whether number of tokens minter does not exceeds max allowance. Then, it call themint
function in theNextGenCore
contract, which calls the_mintProcessing
.The
_safeMint()
checks if recipient refers to a smart-contract. If it does, then it makes an external call to itsonERC721Received()
function, which must return a magic value. However, this allows a minter to reenterMinterContract.mint()
function and mint as many tokens as they want since thetokensMintedAllowlistAddress
mapping is updated only AFTER the_safeMint()
is invoked.So this two requirements won't work:
Tools Used
Manual Review
Recommended Mitigation Steps
Add the non-reentrant modifier to the
MinterContract.mint()
function.Assessed type
Reentrancy
The text was updated successfully, but these errors were encountered: