Freename

The FNSRegistry contract overloads three different versions of the mint() function. Two of these functions do not possess access control and can be called by any account. This effectively means that the minting process, which should be protected and accessible only by the _mintingManager, can be bypassed, and any token can be minted freely.This may result in denying legitimate users the ability to have their bought domains minted by the minting manager.

The function _transferOwnership() does not revoke the roles of the previous owner, i.e. the previous owner keeps the DEFAULT_ADMIN_ROLE. With this role, the previous owner may add himself back or other malicious users as minters and takeover the system completely.

The BaseForwarder smart contract and its child contracts provide a custom implementation of the ERC2771. Essentially, it allows an untrusted third-party address to pay for a transaction performed by a previously set trusted forwarder. This mechanism uses signature verification to validate that the meta transactions are indeed authorized.The custom verification implemented on the function _verify() requires the signed message to contain the following values:Request's data;Target contract of the transaction;Request's nonce;Blockchain ID.The vulnerability identified in this implementation is the fact that the provided nonce is not global and varies depending on the provided tokenId argument. Specifically, each time a transaction is performed via a trusted forwarder, the previous nonce for the tokenId provided as an input parameter is invalidated. This means that, at any specific time, several tokens can have the same current nonce. And since the tokenId is not part of the signed message, it can be freely modified by an attacker that attempts to use the same signature on a future transaction.Moreover, not every function call of the target contracts deals with tokens and requires a tokenId as an input parameter. In this case, this particular vulnerability becomes more apparent and dangerous. Examples of such functions are disableBlocklist(), pause(), sendToBridgeWithTokenOwnerSignature(), etc.As an example, the following proof of concept can be considered:A meta transaction is performed legitimately via a trusted forwarder. This transaction will have have a nonce equal to 0 and associated to the tokenId 1000.An attacker calls the function execute() with the same signature and the same arguments, except that it modifies the associated tokenId to 1337, which is provided as an input parameters. The current nonce for this tokenId is also 0.The verification of the signed message does not take into account the different tokenId, but it does verify that the nonce is valid. Since the current nonce of the tokenId 1337 is also 0, then the signature is validated, just as it was for the legitimate transaction with the tokenId 1000.

The state variables _mintingManager and _propertyManager on the FNSRegistry contract are initialized once and can never be modified again. This effectively means that if the accounts associated with the addresses stored on the state variables become compromised, the entire protocol may be at risk.

The functions initialize() on FNSRegistry and MintingManager possess input parameters that require the other smart contract to already be deployed, creating a dangerous loop on the input parameters, i.e:The initialize() function on MintingManager contains the input parameter fnsRegistry_ which should contain FNSRegistry's address.The initialize() function on FNSRegistry contains the input parameter mintingManager which should contain MintingManager's addressOn non-upgradeable smart contracts, these contracts could never be deployed since the constructor is executed during the deployment and the input parameters are not yet know during deployment.On upgradeable smart contracts where initializer functions are used, it is possible to first deploy the contracts and only initialize them afterwards with the necessary input parameters. However, this opens up the possibility of malicious users frontrunning the call to the initialize() function and completely take over the smart contracts. This is especially dangerous when the source code of the protocol is already know and it is being deployed on new blockchains.

The function reset() virtually clears all records of the token by changing its preset. This function does not implement access control and can be called by any account. This effectively means that any user can clear the records of other users's tokens.

An implementation contract should not be left uninitialized. An uninitialized implementation contract can be taken over by an attacker, which may impact the proxy.The contracts FNSRegistry and MintingManager implementations do not disable contract initialization with the usage of the function _disableInitializaers().

The Blocklist smart contract is used to provide a blocking feature to the minting of tokens. Once a token is minted and blocked, purposely or by mistake, it is impossible to unblock it since there is no unblock feature implemented.

The functions _setManyRecords(), _setManyRecordsByHash(), _setManyProperties(), and _setManyPropertiesByHash() do not validate the input arrays keys and values. It is possible for these functions to be called with mismatching input array lengths and allowing transactions to occur on only a subset of the input elements.

The system allows for the minting of the NFT tokenId 0. Throughout the code, there are no validations to account for the existence of such a tokenId. Due to this fact, several scenarios are enabled that do not reflect accurate information on correct possibilities. For example, when the tokenId 0 is minted, every user that has not yet set a default domain, will by default have this token as its default domain.