Christmas Dinner

Summary

The contract fails to update the participant status after a refund and lacks a mechanism to prevent refunded participants from rejoining, leading to potential inconsistencies and exploitation.

Vulnerability Details

1. Missing participant Update: The refund() function does not set participant[msg.sender] = false after a user has been refunded. This allows a user to be refunded but still be considered a participant.

2. No Prevention to Rejoin: There's no mechanism to prevent a user who has already called refund() from calling changeParticipationStatus() to set their status back to true before the deadline.

Impact

• Inconsistent State: A user can be refunded but still appear as a participant in the contract's state.

• Potential Exploitation: A user could refund, rejoin, and withdraw again after the deadline, effectively double-spending.

Tools Used

• Manual Code Review

Recommendations

• Update participant Status in refund(): Add participant[msg.sender] = false; after the refund logic in the refund() function.

• Add a Check in changeParticipationStatus(): Modify changeParticipationStatus() to prevent users who have been refunded from returning their status to true. This could involve adding a new mapping to track refunded users or modifying the existing participant mapping.

  mapping (address => bool) public hasRefunded;

  ​

  function refund() external nonReentrant beforeDeadline {

  // ... (rest of the refund logic) ...

  participant[msg.sender] = false;

  hasRefunded[msg.sender] = true;

  emit Refunded(msg.sender);

  }

  ​

  function changeParticipationStatus() external {

  if (hasRefunded[msg.sender]) {

  revert AlreadyRefunded();

  }

  if(participant[msg.sender]) {

  participant[msg.sender] = false;

  } else if(!participant[msg.sender] && block.timestamp <= deadline) {

  participant[msg.sender] = true;

  } else {

  revert BeyondDeadline();

  }

  emit ChangedParticipation(msg.sender, participant[msg.sender]);

  }