Sparkn

Summary

Two different contestId can have the same salt

Vulnerability Details

The vulnerability refers to the potential issue in the _calculateSalt function. This function is used to generate a unique salt for each contest using the organizer's address, contestId, and implementation address. However, if two different contests have the same organizer and implementation address, they will generate the same salt even if their contestIds are different. This is because the keccak256 hashing function used in _calculateSalt does not consider the order of its input parameters. As a result, two different contests could end up with the same salt, leading to potential conflicts and unexpected behavior in the contract. This could be exploited by an attacker to manipulate the outcomes of contests or disrupt the contract's normal operation.

Tools Used

Manual,Audit Wizard

Recommendations

The issue can be resolved by ensuring that the salt generated for each contest is unique. This can be achieved by including a unique identifier in the salt calculation. One way to do this is by appending the contestId to the organizer's address and the implementation address before hashing them. This will ensure that even if two contests have the same organizer and implementation address, their salts will be different because their contestIds are different.

Here is the updated _calculateSalt function:

By using abi.encodePacked, we ensure that the inputs are concatenated before being hashed, which will generate a unique hash for each unique set of inputs. This will prevent the issue of two different contests having the same salt.