Trick or Treat

Description of the Code Vulnerability

The vulnerability in the Solidity contract's function resolveTrick is related to the unauthorized change of the requiredCost without proper updating mechanisms to previously initiated purchase agreements (i.e., in pendingNFTsAmountPaid).

The function relies on a dynamic calculation of the requiredCost (treat.cost * 2), which is directly tied to the treat associated with the tokenId. If the treat's cost associated with a specific tokenId is changed after a user initiates a purchase but before they complete it, it can put the user in a position where the requiredCost becomes unexpectedly higher. This can happen especially if additional msg.value (ETH) sent aligns with a previously accurate price but becomes insufficient due to a change in treat.cost.

Step-by-Step Exploit Scenario

1. Initial Scenario Setup:

   • Assume a user initiates the purchase of a Treat (represented by a tokenId) whose original cost is X ETH. Therefore, the initially computed requiredCost would be 2X ETH.

   • The user sends a portion of the cost, say X ETH, which is stored in pendingNFTsAmountPaid[tokenId].

2. Cost Amendment by Contract Owner/Admin:

   • Before the user sends the remainder of the required ETH, the treat.cost for the specific tokenId is updated by the contract owner or through another function in the contract, changing treat.cost from X to 2X. Now, the new requiredCost expected becomes 4X ETH.

3. User Completes the Purchase:

   • The user, unaware of the change in pricing, sends an additional X ETH to complete the assumed 2X ETH total price.

   • The function now evaluates the total paid (2X ETH from pendingNFTsAmountPaid[tokenId] + X ETH msg.value) against the new requiredCost (4X ETH), and finds it insufficient.

4. Resulting in Denial of Service or Loss of Funds:

   • The user has now paid 3X ETH but cannot complete the purchase due to the new requiredCost of 4X ETH, leading to either a need for an additional payment or possible loss of funds if the user decides against continuing the purchase.

Explanation

This vulnerability leaves room for unexpected behavior and potential financial loss for users, contingent on external control over the cost parameter of a treat. A suitable fix would involve locking the price at the time of initial payment or implementing mechanisms that ensure users are informed and consent to new prices before additional payments are made. This exploit outlines how a seemingly fair transaction becomes unfair due to unannounced changes in transaction terms, directly impacting user trust and contract integrity.