abi.encode
collision will result in the same salt being generated in setContest
function.
The contract uses salt generation for storing closeTime for contests or deploying them deterministically.
But abi.encode is prone to collisions as described in this Ethereum Exchange Post.
In setContest
, even if the contest is not registered, just because it has the same salt , it will not get registered.
In deploy
functions, this vulnerability will allow to deploy contracts who's salt is same as the one is already registered but might not be registered at the first place.
Following both codes generate the same output using different static and dynamic data:
overwriting closeTime of contests that were registered earlier but had the same salt as one of the new one.
Manual review, Ethereum exchange
https://ethereum.stackexchange.com/questions/113188/can-abi-encode-receive-different-values-and-return-the-same-result
Inspect the collision cases carefully and come up with solutions.
My recommendation would be to include user nonces and block.timestamp for reducing number of collisions
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.