The ChoosingRam
contract provides a function increaseValuesOfParticipants
which "allows users to increase their values (or characteristics) and become Ram for the event". This function takes the token ids of the challenger and any other participants. Based on the random logic it selects to increase the characterics of one of them. However, it allows both token ids to be equal which allows users to challenge themselves and eliminates the random element.
The ChoosingRam::increaseValuesOfParticipants
takes two parameters uint256 tokenIdOfChallenger
and uint256 tokenIdOfAnyPerticipent
which are supposed to be different and also for a different participants but this is never checked in the code. Next, based on the random number calculated in Line 51 the characteristics of one of the two tokens are increased. The missing check allows the users to challenge themselves, which will always increase their own characterics and eventually to become Ram.
The following test demonstrates the vulnerability.
The user who is aware of this vulnerability can become Ram and get the reward. This breaks the logic of the contract.
Manual review
Add the missing check in ChoosingRam.sol
and revert if the two token are for the same participant. The function will revert if the ram address stored in the token of the challenger is not equal to msg.sender
. So, we only need to add a check if the address of the ram stored in the token of the challenged participant is different from msg.sender
. This will, also elimimates the problem with execution of the function with two equal token ids. See the code below.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.