First Flight #2: Puppy Raffle

Vulnerability Details

The withdrawFees function relies on the contract's balance being exactly equal to the totalFees variable to permit the withdrawal of fees. The relevant code snippet is as follows:

This implementation assumes that the only Ether held by the contract will be from the collected fees. However, there can be scenarios where additional Ether is sent to the contract outside of the raffle mechanism, either accidentally or maliciously (via selfdestruct() for example). Such scenarios would cause the contract's balance to deviate from the totalFees variable, effectively locking the funds and preventing legitimate withdrawals.

Impact

The strict reliance on the contract's balance matching totalFees can lead to scenarios where the fees become unwithdrawable, impacting the intended functionality of the contract. This could result in a loss of funds or inability to redistribute them according to the contract's purpose. Moreover, it exposes the contract to potential denial-of-service attacks, where an adversary could deliberately send Ether to the contract to disrupt its normal operations.

Recommendations

• Separate Fee Accounting: Implement a more robust accounting system for fees that does not rely solely on the contract's balance. This could involve tracking the fees in a separate internal variable that is only updated when fees are legitimately collected.

• Safe Withdrawal Logic: Modify the withdrawal logic to allow the withdrawal of up to the amount in totalFees, regardless of the contract's total balance. This would enable the withdrawal of legitimate fees even if additional Ether is sent to the contract.