Project

Summary

The sendProfit function lacks access control mechanisms, allowing any external actor to trigger profit distributions to token holders as long as they have approved tokens. This creates a critical security vulnerability where unauthorized parties can manipulate the profit distribution system, potentially leading to economic damage through malicious profit distribution timing or amounts. Since the contract handles actual value transfer through ERC20 tokens, this vulnerability poses direct financial risks to the protocol and its users.

The root cause is the omission of access control modifiers on the sendProfit function, contrasting with the pattern established throughout the rest of the contract where sensitive functions are protected with onlyRole modifiers. The contract implements OpenZeppelin's AccessControl pattern and defines several roles like OWP_FACTORY_ROLE and DAO_CREATOR, but fails to utilize them for this critical function.

The vulnerability is exacerbated by the fact that the function handles actual token transfers and updates the profit accounting system that determines how much profit each token holder can claim. This system maintains state variables like totalProfit and uses them in conjunction with ACCURACY (1e30) for precise profit calculations, making unauthorized access particularly dangerous.

Vulnerable code snippet

https://github.com/Cyfrin/2024-11-one-world/blob/main/contracts/dao/tokens/MembershipERC1155.sol#L191

Consider a scenario where a malicious actor monitors the mempool for large token holder transactions. Just before a significant token transfer or claim operation, they could call sendProfit with a specific amount, manipulating the profit distribution timing to their advantage. Since profit calculations depend on token holdings at specific timestamps (through the saveProfit mechanism), unauthorized profit distributions could be used to exploit the timing of these calculations, effectively stealing value from legitimate token holders.

Recommended Fix

Add appropriate access control modifier to restrict the function to authorized roles:

Alternatively, if multiple roles should have access to this function, consider creating a new role specifically for profit distribution:

Remember to grant this role appropriately during initialization or through admin actions.