Christmas Dinner

First Flight #31
Beginner FriendlyFoundrySolidity
100 EXP
View results
Submission Details
Severity: low
Valid

Any user can become participant within the deadline, without paying participation fee

Summary

Anyone can become a participant within the deadline without payment, becoming attendee and getting a free dinner at the cost of others.
In addition, making it in the participants list @ mapping (address user => bool) participant automatically makes the user part of the pool of possible _newHost .

Vulnerability Details

Due to the ChristmasDinner::changeParticipationStatus function external visibility, lack of checks and bad business logic, anyone can become attendee and render the participant list useless for the organizer.
The participant mapping is also used as a pool for choosing _newHost in ChristmasDinner::changeHost if and when necessary. It is not stated whether the arrangement between the old and new host would be done off-chain and if the new host is trusted but in the natspec (ln.165) _newHost is an arbitrary user which is participant (and as such he/she should pay a fee). We should assume that anyone (especially non-paying participants) could be malicious and by becoming a host (by omissive, misleading or intentional address input by the old host) would have full access to the protocol's funds and overall setup which would put them at risk.

A simple test proving that anyone can become participant (paste this in the test suite):

function testParticipationStatusChangeWithoutPayment() public {
vm.startPrank(user1);
cd.changeParticipationStatus();
assertEq(cd.getParticipationStatus(user1), true);
cd.changeParticipationStatus();
assertEq(cd.getParticipationStatus(user1), false);
}

Impact

Protocol's funds and core organization idea are at risk in two possible ways:

  1. A random user could become a participant for free and would have dinner at the cost of others.

  2. A possibility exists by becoming _newHost, for a malicious user to drain the funds and/or making non-acceptable changes of the setup of the protocol.

Tools Used

Manual review, Foundry

Recommendations

  1. Either remove the part of the ChristmasDinner::changeParticipationStatus function that stores users in the participant mapping:

    ...} else if(!participant\[msg.sender] && block.timestamp <= deadline) {
    participant\[msg.sender] = true;...
  2. ...or remove the function entirely, hindering indecisive users from participating in the event.

Updates

Lead Judging Commences

0xtimefliez Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

usage of change participation logic circumvents deposit

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!