Closed code423n4 closed 1 year ago
seems invalid
no clear impact/loss
141345 marked the issue as duplicate of #386
0xean marked the issue as unsatisfactory: Invalid
0xean changed the severity to QA (Quality Assurance)
0xean marked the issue as grade-c
Hello @0xean, Thank you for taking the time to review my submission. Upon receiving your feedback, there are several points I would like to address and possibly clarify. I believe the following information might be helpful in re-evaluating my submission:
p.s. When I wrote this submission, I used the ever-present problem of unauthorized proposal execution in Governance as an example. For instance, the significance of the proposal executor post-voting, as they can set the Gas, and utilize the 1/64 rule to mark a proposal as executed without its actual implementation.
In my tests, I aimed to showcase potential cases that could occur and the repercussions of unauthorized minting. In summary, unauthorized minting offers the following possibilities:
Through my tests, I wanted to convey that an unauthorized NFT minting user could exert enough influence to cause losses, unexpected behavior, or NFT locking.
I hope this clarifies my submission's scope and the potential issues it raises. I appreciate your time and consideration in re-evaluating it.
Thank you, have a nice day
This is QA at best, certainly overinflated severity. Leaving as graded.
Lines of code
https://github.com/code-423n4/2023-07-arcade/blob/f8ac4e7c4fdea559b73d9dd5606f618d4e6c73cd/contracts/nft/ReputationBadge.sol#L98
Vulnerability details
Title: Unauthorized users can mint NFT for other authorized users
Impact
Any unauthorized user can mint Non-Fungible Tokens (NFTs) for other authorized users, which could result in unexpected and undesirable behaviors.
If the NFT price is set to 0 (for exampel: NFT airdrop), it could lead to an easy attack, where the user only pays for the transaction fee.
Example of unexpected/undesirable behaviors:
Precondition: the recipient is a contract that processes incoming NFTs and issues operator rewards.
An unauthorized user will be set as the operator in the
onERC1155Received()
call if the recipient is a contract, which could lead to unauthorized users benefiting from these actions or potential losses for the recipient.Precondition: the presence of non-existent addresses in
claimRoots[tokenId]
.An unauthorized user can mint the entire NFT limit to a non-existent/invalid address.
Precondition: the recipients are contracts with specific logic.
An unauthorized user mints NFTs to a contract that cannot properly process them or has behavior that prevents proper future use of these NFTs (for example: authorized NFT withdrawal where the NFT arrived sooner than expected, and another user withdrew it from the contract).
Precondition: the recipient is a contract implementing specific logic upon receiving NFTs with try/catch.
An unauthorized user, by manipulating
gasLimit
, can take advantage of the1/64 rule
and lead to unexpected consequences/losses.Proof of Concept
Instances:
nft/ReputationBadge.sol#L98
address recipient, uint256 tokenId, uint256 amount, uint256 totalClaimable, bytes32[] calldata merkleProof ) external payable { uint256 mintPrice = mintPrices[tokenId] * amount; uint48 claimExpiration = claimExpirations[tokenId];
if (!_verifyClaim(recipient, tokenId, totalClaimable, merkleProof)) revert RB_InvalidMerkleProof(); if (amountClaimed[recipient][tokenId] + amount > totalClaimable) { revert RB_InvalidClaimAmount(amount, totalClaimable); }
_mint(recipient, tokenId, amount, ""); }
address operator = _msgSender();
_doSafeTransferAcceptanceCheck(operator, address(0), account, id, amount, data); }
function _doSafeTransferAcceptanceCheck( address operator, address from, address to, uint256 id, uint256 amount, bytes memory data ) private {
if (to.isContract()) {
try IERC1155Receiver(to).onERC1155Received(operator, from, id, amount, data) returns (bytes4 response) { if (response != IERC1155Receiver.onERC1155Received.selector) { revert("ERC1155: ERC1155Receiver rejected tokens"); } } catch Error(string memory reason) { revert(reason); } catch { revert("ERC1155: transfer to non ERC1155Receiver implementer"); } } }
The following tests want to show only great variability and problem areas that can serve as proof of the validity of the problem
Example tests demonstrating various types of unexpected or bad behaviors:
Result:
Tools Used
Recommended Mitigation Steps
It is recommended to only allow minting if the recipient equals
msg.sender
, or by using a signature scheme where only the authorized sender can mint the tokens for recipient by signature from recipient. Adding this requirement can prevent unauthorized users from minting tokens on behalf of others, ensuring that only authorized users can mint tokens.Assessed type
DoS