There is no checking whether the one who registered is a Person (EOA) or a Smart Contract, also there is no checking for registration time limit.
ThePredicter.sol::register()
is a function where a User can register to become a Player by paying the entranceFee
. However, the function itself doesn't check if the subject, who is registering is a "real person" or a Smart Contract, leading to a possible occurrence of a Reentrancy Attack.
The impact of the missing validation in this function can lead to many scenarios, 2 of the scenarios that are important to note are:
Smart Contract can also register as a Player, which opens an opportunity to do exploits that require smart contracts such as reentrancy.
A user can deploy a multiple smart contract to interact and register, potentially filling out all the remaining 14 slots (or 13 smart contracts + 1 EOA), and if all the accounts are verified (approved), the original EOA / user may have a bigger chance to win and add more prediction to the match.
Scenario #1: Smart Contract can register as a Player
Using Foundry:
Create a simple smart contract that will interact with ThePredicter.sol
Here is a simple one
add the following code to the ThePredicter.test.sol
run forge test --mt testFor_SmartContractRegistration() -vvvv
Using REMIX IDE
Deploy both smart contracts on REMIX
create. a new Smart Contract to test the register()
function, like this
Call the function register()
to test the function and supply it with the correct entranceFee
call the ensureIsRegistered()
function and ensure that the value is 1
Scenario #2: A User deploys 13 Smart Contracts and also does the register function.
NOTE: This scenario is only valid if the organizer
accidentally marked all 14 registrations (13 Smart Contracts and Smart Contract Owner Account) as approved
Create a Smart Contract that can interact with the ThePredicter.sol
and Register, such as below
Add this to the ThePredicter.test.sol
run forge test --mt test_MultiplerSCRegistration() -vvvv
Foundry
REMIX IDE
Adding a verifier for verifying that the registration is an EOA is necessary to prevent the scenario mentioned above, to do this we can use the tx.origin
method, below is the suggested fix for the code
The suggested fix above will check whether the player candidate is an External Owner Account (EOA), with that check, it will also check for the tx.origin
which will point to an EOA, preventing a Smart Contract from registering.
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.