Project

Summary

Because ENS name strings are not unique, multiple users can create a DAO membership for the same ENS name.

Vulnerability Details

ENS names are normalized before they go through their namehash algorithm: https://docs.ens.domains/resolution/names
This means that many strings map to exactly the same ENS name. For instance, test.eth and TeST.eth map to the same ENS name (and there are many more because of special Unicode characters, see the article for details).
The unnormalized ENS string is therefore insufficient to enforce uniqueness, but this is exactly what the contract is doing: https://github.com/Cyfrin/2024-11-one-world/blob/02b59f43981d247caee9aa9ab68d286ce7844a77/contracts/dao/MembershipFactory.sol#L60

Note that it is visible within the tests (https://github.com/Cyfrin/2024-11-one-world/blob/02b59f43981d247caee9aa9ab68d286ce7844a77/test/MembershipFactory.test.ts#L63) that the expected behavior for this field is indeed to pass in a name and not a name hash.

Impact

An attacker can create multiple DAO memberships for ENS names where one already exist. For the user, it will be unclear which is the "correct" (i.e. the one that was created first) membership, as the frontend HAS TO normalize the names (otherwise it would be an invalid ENS integration, see the namehash section here: https://docs.ens.domains/resolution/names#namehash). The other memberships could have completely different fees and the attacker probably would be able to extract those fees (depending on the membership implementation, which was out of scope).

Recommendations

Instead of using names, use the namehash in the contracts for ensuring uniqueness. This is the only recommended way of ENS to ensure uniqueness / use them as identifiers in a contract.