CommunityId Overflow DOS#

Vulnerability#

In CommunityToken.sol, the communityId and communityMemberCounter variables are both uint24 variables. This low value makes it feasible for a malicious governance NFT holder to deny service from other holders by using up all of the available communityIds.

Exploit Example#

The attacker could accomplish this by transferring their unwrapped nft to a newly generated address, then proceeding to wrap and unwrap with a new address, causing communityMemberCounter to increment on line 152 of CommunityToken.sol. The attacker can repeat this until they have reached the upper bound of community ids available. At that point, no new NFT holders would be able to acquire a CommunityToken due to an overflow revert.

To be clear, on mainnet this would be a very expensive and slow attack under current conditions and likely infeasible.

Example economics of the attack:#

• Approximate gas cost to wrap, unwrap, transfer tokens: 300,000 gas.
• To use up the available 2^24 tokenIds would cost: 2^24 * 300,000 = 5,033,164,800,000 gas. Note: If someone were implementing communityToken w/o disabling transfers, you can increment with only ~50,000 gas via transferFrom so it would be ~1/6 cheaper.

At current gas / eth prices (7PM Saturday, Sep. 17th):

• ETH Price: $1456.00
• Gas Price: 3 Gwei

The total cost to overflow the communityIds would be about $22M in gas.

We list this as low risk only if the intent is for the contracts to be used across chains. For instance on Polygon you could overflow communityIds for ~$120,000.

Recommendation:#

Modify communityId and communityMemberCounter to uint240 rather than uint24 . This makes intentionalcommunityMemberCounter overflow computationally infeasible, even with several orders of magnitude cheaper gas than any chain currently available. This has the added benefit of more efficient slot packing without the need for padding (which was likely the original intention).