Sparkn

Summary

Different implementation contracts can be used for different types of contest payouts. If organizer signs a message for implementation A, it can be used to trigger a payout also with implementation B.

Vulnerability Details

The function setContest takes a field implementation. Thus it can be assumed that there will be multiple implementation contracts, with the same or different logics for payouts. But this fact is not incorporated in the signatures.

Assume there are two implementation contracts, A and B. The organizer starts contests using both implementations with the same contestId at the same timeframe. Since the implementations are different, the salt calculated will also be different, making them sufficiently unique.

This can give the assumption that multiple implementations are supported at the same time. But if the organizer signs a message to execute the contest running with implementation A, the same signature can be used to execute payments for contests running with implementation B as well! This is because the signature digest only has contestId and the payout data.

Thus say a user wins the contest running with implementation A. If there is another contest with the same id running with implementation B, the organizer can just use the same signature and same data to trigger a payout for contest B as well. Since the user already won contest A, their name is already in the data parameter and they will get a payout for contest B as well.

Impact

Users can re-use signatures for different contests with different salts.

Tools Used

Manual Review

Recommendations

The signature digest should also include the salt. This would ensure that only a single unique contest can be payed out with a single signature.