cometh-hq / alembic-rental-contracts

2 stars 1 forks source link

Front-running in the Cometh Rental contracts #9

Open Mikerah opened 2 years ago

Mikerah commented 2 years ago

The goal of this issue is to go over a few different ways that the current contracts are susceptible to various front/back running attacks, their potential effects on Cometh Rental users and potential mitigations. As such, it is mainly informational.

Summary

Overall, the main kinds of front-running attacks that are relevant for the Cometh rental contracts are displacement attacks and insertion attacks. In terms of importance, insertion attacks will affect users more than displacement attacks as these attacks will affect how the user views the fairness of playing Cometh with another player's NFT(s). The main ways in which such attacks are possible is if the lender is a miner or otherwise has control over how they handle rental related transactions.

Displacement Attacks

Displacement attacks are a kind of front-running attack in which the order in which a player calls a rental function is not important to the malicious renter. Concretely, a malicious renter can put up a public rental offer and then wait until several users have submitted their calls to the rent function before the malicious renter under a different account (in fact, this second action could just be done by someone who is not the renter but that has a lot of money. Without loss of generality, assume the original case presented) simply calls the rent function in a transaction with a higher gas price then the other potential tenants. Then, the prospective tenants calls for that specific rental offer have no effect has the tenant controlled by the renter is now under a lease. This scenario can also be applied in the case that a tenant wants to sublet their Cometh NFTs. We note that this kind of attack is of low severity as potentially losing out on a rental offer due to another user being faster is most likely an expected outcome for players of Cometh.

Insertion Attacks

Insertion attacks are a kind of front-running attack in which the order in which a player calls a rental function matters to a potentially malicious renter or other player as the malicious entity wants the other player to run on their (the malicious entity) modified state as opposed to the previously neutral state. This is the most concerning kind of front-running attack as we have seen in practice the effects on users. We highlight several cases in which insertion attacks can affect players in Cometh.

Scenario 1

  1. Maker creates a rental offer for a public rental
  2. A user tries to rent the NFT(s) for the particular offer
  3. Maker doesn't like that user and sends a cancelRentalOffer order with a higher gas price in order to cancel the offer before that user can take the rental offer.

Scenario 2

Consider the setting of scenario 1 but the maker iteratively decides to cancel offers before anyone can take the rental offer. This would affect the gameplay of Cometh hence making the user experience suboptimal.

Mitigations

As Cometh is an NFT game, there is an important tradeoff between costs, and time delays that can affect the accessibility of playing the game. As such, many traditional mitigations in order to minimize front-running such as adding a fee for making a rental offer or batching offers may be suboptimal. In order to better understand Cometh's users' expectations around front-running, it would be best to conduct a user survey and then decide on a reasonable mitigation strategy based on the survey results.

jeje commented 2 years ago

Displacement Attacks & Insertion Attacks: Thanks for this valuable feedback. We will take this into consideration for our later improvements.

As such, many traditional mitigations in order to minimize front-running such as adding a fee for making a rental offer or batching offers may be suboptimal. In order to better understand Cometh's users' expectations around front-running, it would be best to conduct a user survey and then decide on a reasonable mitigation strategy based on the survey results.

Good point. Currently our front-end enforces a >= 0.1 MUST rental cost and we won’t index rental offers with less than this amount in our subgraph, so such offers would not be visible through our marketplace.