Project

Summary

In the createNewDAOMembership function, the contract is created using the CREATE opcode, with its address solely based on the nonce of the MembershipFactory contract. Since CREATE2 is not used, which would otherwise provide deterministic address generation through a salt, the current approach makes the contract susceptible to reorg attacks. In a reorg scenario, this vulnerability allows a malicious actor to potentially manipulate and control the contract’s deployment address by executing their transaction on an identical address before the legitimate transaction is confirmed.

References

• MembershipFactory.sol on GitHub

Proof of Concept (PoC)

1. A legitimate user initiates the createNewDAOMembership function to create a DAO.

2. A reorg occurs, and an attacker with a reorg bot identifies this reorganization event.

3. The attacker replicates the creation transaction, capturing the targeted address before the original transaction is re-executed after the reorg.

Potential Impact

The legitimate user’s transaction either fails or, in cases where funds or functionality are involved, mistakenly interacts with the attacker’s address.

Notable Reorg Events on Polygon

Since this project is intended for the Polygon network, it’s critical to address this vulnerability due to Polygon’s reorg history, including significant events:

• A reorg of 120 blocks on Polygon two years ago caused roughly four minutes of re-executed transactions due to Polygon’s block rate of approximately two seconds.

• In another instance, Polygon experienced a 157-block reorg last year, which impacted numerous transactions across the network.

• Forked block records on PolygonScan show frequent minor reorg events, indicating ongoing susceptibility.

These events highlight the reorg risks on EVM-compatible networks like Polygon, underscoring the importance of using CREATE2 for predictable and secure contract address generation.

Tools Used

Manual

Recommendation

Implement CREATE2 for deploying new contracts, using a salt based on user-specific values such as msg.sender. This modification will mitigate reorg attack risks by ensuring contract addresses are uniquely tied to each user, thus reducing the likelihood of address manipulation through reorg events.