There is no way to resend a request to the randomizer

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/NextGenCore.sol#L178-L184

Vulnerability details

Impact

In the contract, when minting NFT, a request is sent to the randomizer to obtain a random hash. In cases where a randomizer from chainlink or arrng is used, then the hash request is an asynchronous operation. The hash is established after several blocks after the NFT mint. There may be several situations when it is necessary to re-send the request to the randomizer. But there is no such possibility in the contract.

Chainlink uses a subscription method to pay for its work. First you need to top up your subscription balance with tokens and with each hash request, chainlink tokens will be debited from the subscription balance. If the balance is not sufficient to pay for the request, it is enough to top up the subscription balance within the next 24 hours. And after that, the chainlink itself will send a random number to the contract.

If you do not replenish the balance within 24 hours, then in order to receive a random number, it is necessary for the contract to send a request to the chainlink again. But there is no such possibility. Even the project administrator.

It may happen that the subscription balance runs out, and the project owner does not have time to replenish it. In this case, NFTs that users have without a hash will remain forever without it.

This is not about the fact that the project owner will not replenish the account on purpose, but about the fact that this can happen by accident, under different circumstances. There is a risk that the administrator simply will not have time to top up the subscription account within 24 hours. And it must be taken into account.

Proof of Concept

The request to the randomizer is sent only from internal function NextGenCore._mintProcessing() such when minting NFT and it is impossible to send it again

    function _mintProcessing(uint256 _mintIndex, address _recipient, string memory _tokenData, uint256 _collectionID, uint256 _saltfun_o) internal {
        tokenData[_mintIndex] = _tokenData;
        // HERE
        collectionAdditionalData[_collectionID].randomizer.calculateTokenHash(_collectionID, _mintIndex, _saltfun_o);
        tokenIdsToCollectionIds[_mintIndex] = _collectionID;
        _safeMint(_recipient, _mintIndex);
    }

Tools Used

Manual review

Recommended Mitigation Steps

Add function, which give opportunity to admin resend request to randomizer.
It is safe opportunity, because in function NextGenCore.setTokenHash() there is check, that hash is still bytes32(0). So, if even admin call function after success request to randomizer, it will not cause problem.

Assessed type

Oracle

[c4-pre-sort]

141345 marked the issue as duplicate of #1307

[141345]

related to #1464

[c4-judge]

alex-ppg marked the issue as unsatisfactory:
Invalid

[SovaSlava]

Thanks for judging.
In #1464 (comment) sponsor said:
"if it fails due to lack of funds it will fail also when re executed".
Its wrong, because, if second request will be done, when chainlink subscription have enough funds, it will not revert.
My issue is about opportunity for users, to have special function - resendRequest, which could be called manualy by users. Not automatically. So, If request to vrf fail by insufficiently funds, user can call function resend after 1 day(for example) and if after 1 day subscription will have enough funds, call will be success.

Also, sponsor said: "If the tokenHash has not been set an admin can deploy a contract that can call the RNG for that specific id, the hash will be generated and stored".

RNG randoms is not the same as VRF. If before this, randomizer was VRF, users would like, that hash will set exactly by VRF.
Also, if will be big amount of users, if will be expensive recall for all of them randomizer again.

"The contracts will be fully funded to cover the costs." - its just promise, Yes, owner is trusted, but could be different situations ..

[alex-ppg]

Hey @SovaSlava, thanks for your contribution! Your recommended course of action is to permit the administrator to resend a randomness request, meaning that they will have to supply the necessary funds to fulfill it.

In any case, I believe such a recommendation is better suited under an Analysis or QA submission and cannot constitute a medium-severity vulnerability, rendering my initial verdict to remain.

[SovaSlava]

@alex-ppg Thanks for answer. So..may be you can grade this issue as qa grade-b, please?