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

6 stars 2 forks source link

PNS - `buytickets` function can be completely blocked under high demand #593

Closed sherlock-admin3 closed 3 months ago

sherlock-admin3 commented 3 months ago

PNS

Medium

buytickets function can be completely blocked under high demand

Summary

As outlined in the document provided by the sponsor: https://docs.google.com/document/d/12kGD8nJ9DiR0cW5ngT8A6gE7GBG7NwiDCOIkGksL8qY/edit, the process of buying tickets begins with an HTTP request to the API, which returns the available number of tickets, the purchase price, and a signature. The number of tickets is then validated by the _checkTicketPurchaseable function and checked against the possible supply, as seen here. Due to the asynchronous nature of these requests, it’s possible that the data and signatures could be generated just before another user completes a purchase, rendering the API data outdated and causing the transaction to revert, effectively paralyzing one of the application's core functions.

When trying to purchase tickets, an HTTP request goes to our API to specify the address of the buyer and the chosen bundle, the response will include the price to pay, the actual number of tickets (after computing potential bonuses and ensuring we don’t exceed the ticket supply or the max holding), a nonce and an ECDSA signature that will allow the contract to verify that this purchase is valid

Root Cause

Signatures and data are generated based on data at a specific moment without considering previous purchase transactions, leading to inconsistencies when other users buy tickets.

Internal pre-conditions

  1. The raffle is created.
  2. There is a possibility of purchasing a large number of promotional ticket bundles, causing the API data to differ from what is shown on the website.
  3. High demand for the raffle and a large volume of API requests.

External pre-conditions

No response

Attack Path

No response

Impact

Most purchase transactions initiated through the buyTickets function will be rejected due to outdated data (ticketCount). This will cause the application's core ticket-buying feature to not function as intended.

PoC

No response

Mitigation

The buyTickets process should involve some form of reservation system for the requested number of tickets. This reservation should be factored into subsequent requests to prevent multiple users from purchasing "the same" tickets. The reservation should also have a time limit to allow other users to purchase tickets if the original user decides not to complete the transaction.

sherlock-admin3 commented 2 months ago

escalate

You've deleted an escalation for this issue.