Summary

The functions getProxyAddress(bytes32 salt, address implementation) and _deployProxy(address organizer, bytes32 contestId, address implementation) both calculate the address of the proxy and in the second instance, deploy that same proxy. The 2 functions return unmatching results.

Vulnerability Details

The primary use of the getProxyAddress is to generate a proxy address to send tokens before deployment. But due to the 2 functions using different opcodes, create and create2, there is a mismatch between the provided addresses which leads to direct loss of funds when tokens are sent to the wrong address.

The POC I provide in this github gist was written in Remix with a 'salt' value hardcoded to '123'. The main contract with the calculations is the Compare contract. It's functions address1 and address2 are to be invoked with the same implementation address. They are a copy of the ProxyFactory functions mentioned above.

Link: Github POC

Screenshot of my Remix IDE with highlighted results of the test I ran: Image Proof

The green highlights the implementation address, the yellow and red highlight the 2 different results.

Impact

Likelihood: High, as the feature of pre-sending funds offers better UE

Damage: High, as all funds sent will either be lost or stuck.

Tools Used

Manual Review

Recommendations

Stick to the usage of create2 that is used in the getProxyAddress function when deploying the proxy in the other function via assembly, like: