search

bartervg / barter.vg

Track and hold discussion on Barter.vg bugs, enhancements, and other issues
https://barter.vg
MIT License
20 stars 4 forks source link

Another user became inactive due to an offer I was editing [⏬] #213

Closed Luckz closed 3 years ago

Luckz commented 3 years ago

Describe the bug

https://barter.vg/u/427/o/3877485/ made https://barter.vg/u/2180/ go inactive, but at the time of offer expiry, the offer itself was not active and rather in the edit state.

Steps to reproduce the bug

  1. pick a victim
  2. send an offer with shortest possible expiry time
  3. before the user can / does react, keep the offer in the editing (creating) stage, which they're defenseless against
  4. enjoy seeing them go Unavailable

Expected behavior

Offers that are being edited / created should not expire for other reasons than the edit process not being finalised in XY time.

Additional context

I propose abusing this for non-consensual war-offering gets the perpetrators permabanned. Especially for our beloved resellers, such an attack could endanger 📉 their income and thus their very livelihood.

Tecfan commented 3 years ago

Did you edit the offer constantly over 24 hours? Isn't that the shortest possible expiry time?

bartervg commented 3 years ago

Thank you for reporting this. This looks to have high abuse potential.

There are different queries to select expiring offers (which have been sent), and cancelling offers (which have not). Unfortunately, editing an offer places the offer into both categories. Cancellation occurs after expiration, and cancel uses the time of modified rather than from_expire.

Here is the query that finds expiring offers WHERE to_status = 'pending' AND from_status != 'cancelled' AND from_status != 'paused' AND from_expire != 0 AND from_expire <= ?

Initially, I added AND from_status != 'creating' but this creates an ongoing problem of needing to add new statuses to avoid breaking the query.

I modified it to WHERE from_status = 'proposed' AND to_status = 'pending'

bartervg commented 3 years ago

With the change, I wasn't able to reproduce this expiration attack. This offer https://barter.vg/u/a0/o/3912363/ cancelled harmlessly without setting luckz to unavailable. It may be useful to have an activity feed line for when offers are cancelled automatically.

This bug was mitigated by the strict enforcement of minimum expiration days. Since offers being edited are cancelled after 3 hours, the window for this to happen is small, especially for those with many minimum expiration days.

For the prompt disclosure, luckz received a bug bounty of 5000 gems.

Luckz commented 3 years ago

For the prompt disclosure, luckz received a bug bounty of 5000 gems.

I proposed (or even decreed) a recommended bug bounty value of one (trading) card before. How about we make 333 gems the norm? That's still good value for a card.

bartervg commented 3 years ago

How about we make 333 gems the norm? That's still good value for a card.

Yes, you did, but you didn't claim the card and a -4667 gem penalty assessed.

I'm not sure what would be an effective bug bounty payout schedule, but 1 trading card seems too low.