Core Contracts

Summary

The current implementation of the salt in the hashOperationBatch function does not provide sufficient protection against hash collisions. The salt is derived solely from the descriptionHash, which may lead to potential vulnerabilities if two different proposals have the same description.

Vulnerability Details

The vulnerability lies in the _queueProposal function, where the salt is calculated using only the descriptionHash. The descriptionHash is generated from the proposal's description, which may not be unique across different proposals. If two proposals have the same description, they will produce the same descriptionHash, resulting in identical salts. This lack of uniqueness increases the risk of hash collisions.

Code Snippet

https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/proposals/TimelockController.sol#L325

https://github.com/Cyfrin/2025-02-raac/blob/89ccb062e2b175374d40d824263a4c0b601bcb7f/contracts/core/governance/proposals/Governance.sol#L490

In the _queueProposal function, the salt is derived from the descriptionHash:

Impact

• Hash Collisions: Two different proposals could end up with the same.

Since the proposal must pass the voting period before it can be queued and the hash is calculated, the current implementation could lead to problematic scenarios. A user might create a proposal that successfully passes the voting phase, only for it to revert during execution due to a hash collision. This could result in wasted time, resources, and user frustration.

Tools Used

• Manual code review

Recommendations

To mitigate this vulnerability, it is recommended to enhance the uniqueness of the salt by incorporating additional unique identifiers, such as the proposer's address. This will significantly reduce the risk of hash collisions and improve the overall security of the system.