sherlock-audit / 2024-08-winnables-raffles-judging

6 stars 2 forks source link

PNS - Attacker can block the winner from claiming the prize #546

Closed sherlock-admin3 closed 3 months ago

sherlock-admin3 commented 3 months ago

PNS

High

Attacker can block the winner from claiming the prize

Summary

After a raffle concludes and a winner is selected, any user can call the propagateRaffleWinner function to send the winner's details to the prize manager, enabling the winner to claim the prize using the claimPrize function. However, an issue arises because the propagateRaffleWinner function does not validate the user-provided data. This allows an attacker to send a CCIP message to any contract, changing the raffle's status to PROPAGATED. If the winner's information does not reach the prize manager, they will be unable to claim the prize, and the altered raffle status will prevent the propagateRaffleWinner function from being called again.

Root Cause

The lack of validation for parameters passed to the propagateRaffleWinner function (prizeManager, chainSelector).

Internal pre-conditions

  1. The raffle winner is selected.
  2. The raffle has a FULFILLED status (the VRF returns a random number).

External pre-conditions

No response

Attack Path

  1. The attacker monitors the status change of the raffle on Avalanche, either by observing the mempool or listening for the WinnerDrawn event.
  2. Upon status change, the attacker calls the propagateRaffleWinner function with parameters that allow the transaction to succeed but without sending the message to the PrizeManager.

Impact

  1. The protocol incurs a loss due to CCIP transmission fees in WinnablesTicketManager caused by the attacker.
  2. Since the winner's information never reaches the prize manager, they will be unable to claim their prize using the claimPrize function.

PoC

No response

Mitigation

If the propagateRaffleWinner function is intended to be available to everyone, the data provided by the user should be validated, allowing only the appropriate prizeManager and chainSelector.

A good solution could be to set these parameters (since they are immutable for the chain) beforehand so that they don't need to be provided as function arguments.

The final solution should align with the application's design decisions.

Duplicate of #50