Project

Summary

Due to the reliance on MembershipFactory address and nonce during DAO creation, reorgs on the Polygon chain could direct users to join incorrect DAOs, resulting in potential fund loss and unexpected costs.

Vulnerability Details

The project is set to deploy on the Polygon chain, which can be subject to reorg attacks.

The createNewDAOMembership function creates a new DAO membership by deploying a proxy as shown below:

The proxy address relies solely on the MembershipFactory address and its nonce, making it vulnerable in a reorg scenario. If a reorg alters the sequence of transactions, the previously assigned daoMembershipAddress could end up pointing to a different DAO.

Consider this scenario:

1. daoA is created and assigned address1.

2. User bob decides to join daoA by approving tokens for address1 and calling joinDAO.

3. If a reorg occurs, daoB’s transaction may precede daoA’s, resulting in daoA inadvertently receiving address2 and daoB receiving address1. (daoB could be malicious, or it's just a coincidence)

4. Consequently, when Bob’s transaction is confirmed, he joins daoB instead of daoA, which is not what he wants, causing loss of funds, especially when daoB's price is higher than daoA's.

Impact

This vulnerability allows for funds to be directed to unintended DAO contracts in case of a reorg, creating the potential for loss of funds or unexpected transaction costs for users who inadvertently join the wrong DAO.

Tools Used

Manual

Recommendations

To mitigate reorg-related risks, incorporate ensName and daoCreator verification within the joinDAO function. This will help ensure the correct DAO is joined even if reorgs occur. Also this could strength the function's robustness in case of user error.