HardhatFoundry
30,000 USDC
View results
Submission Details
Severity: low
Valid

Adding a new attester in the RegistryFactory will result in a DOS of the RegistryFactory

Lines of code

https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/factory/RegistryFactory.sol#L57-L59

Impact

When adding a new attester to the attester array by calling addAttester(), it is not ensured that the attesters are “in order”. This will result in a revert of the function “createAccount()” when the registry function “trustAttesters()” is called. The result will be that no new accounts can be created with the RegistryFactory.

Proof of Concept

The RegistryFactory is used to create new Smart Accounts. Users can add specific modules to such a Smart Account to e.g. automate specific task. For a module to be addable to a Smart Account, it needs to be seen as “trusted” in a registry. For a module to be “trusted” it needs to have enough attestations from specific attesters in the registry. The factory determines which attesters are considered and how many attestations are needed.

The registry used to check if a module is trusted or not will follow ERC-7484 for maximal compatibility.

When the factory creates a new Smart Account, it first checks if the modules are trusted in the registry and adds all modules to the account. As a final step, the registry for the account is set and the array of attesters as well as the number of needed attestations is saved in the registry by calling registry.trustAttesters(threshold, attesters); .

According to ERC-7484, when calling trustAttesters, the provided array of attesters “MUST be unique and sorted and the Registry MUST revert if they are not.”

The issue arises from the fact that when the owner of the RegistryFactory calls addAttester(), the new attester is just pushed to the end of the array, thereby (in most cases) breaking the sorted nature of the attesters array.

function addAttester(address attester) external onlyOwner {
attesters.push(attester);
}

Since the array is used to call registry.trustAttesters(threshold, attesters);, this function call will revert (because the array is not sorted) and will thereby prevent any new Smart Account from being created.

Recommended Mitigation Steps

Make sure, when adding a new asserter to the asserter list, that the array is still sorted afterwards. This can be for example done by taking the existing attesters array, determining at which position the new attester should be added and “pushing” all attesters one slot further.

Updates

Lead Judging Commences

0xnevi Lead Judge 11 months ago
Submission Judgement Published
Invalidated
Reason: Other
Assigned finding tags:

finding-ERC7484-sorted-duplicate-attestor-issue

Invalid, similar issue to #151 and duplicates - Addition of attesters are admin only functionalities so if duplicate addresses are added it would consitute admin input/call validation. - ERC-7484 is in draft mode so we should not take it as the final EIP configuration yet. - In the [documentation](https://github.com/bcnmy/nexus/wiki#problems-nexus-solves), it is not noted that Nexus suite will be ERC7484 compliant.

Appeal created

0xnevi Lead Judge 11 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-ERC7484-sorted-duplicate-attestor-issue

Invalid, similar issue to #151 and duplicates - Addition of attesters are admin only functionalities so if duplicate addresses are added it would consitute admin input/call validation. - ERC-7484 is in draft mode so we should not take it as the final EIP configuration yet. - In the [documentation](https://github.com/bcnmy/nexus/wiki#problems-nexus-solves), it is not noted that Nexus suite will be ERC7484 compliant.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.