Security Disclosure: V1 Artwork Bugs

[simondlr]

There exists 3 medium-severity bugs which can lead to loss of funds, or the contract not functioning as expected.

There is currently NO funds at risk as-is. Funds are at risk when buying or topping up the deposit.

Front-Running (2 edge-cases):
If you choose to buy, a malicious user could front-run the buy, and steal part of your deposit, by raising the price, before your buy is executed.

Take the following example: If the price of the artwork is 1 ETH, and you choose to buy it with 9 ETH deposit (sending in total: 10 ETH), a malicious user can execute the buy at 1 ETH before yours clear, and raise the price to say, 8 ETH, upon which your buy will still execute, but will leave you with a smaller deposit. This is a profitable attack as long as the price is less than the deposit, otherwise it's merely a costly griefing attack. To protect against this, send an initial small deposit to buy it, and then topping it up afterwards.

eg: With the price at 1 ETH, buy the artwork, and send along a 0.1 ETH deposit (total: 1.1 ETH). An attacker would lose 1 ETH from buying it, but can only make 0.1 ETH before your buy is executed.

That being said: topping up a deposit is ALSO vulnerable to front-running.

A deposit can be executed by anyone and is not determined by sender. Thus: if you top it up with say 10 ETH, someone can buy the artwork before the deposit is executed, and the new owner will receive the 10 ETH. The same solution applies to the buying front-running. Only submit a top-up that is less than the price. This can be done in increments if need be.

Blocking Sale of Artwork:
If a user buys this artwork from a contract that reverts on ETH sends, it can hold the artwork forever (until their deposit runs out), effectively blocking sale of the artwork. It thus, in effect, does not remain always on sale. However, the attacker can't withdraw their funds either. Thus, it will be held until the deposit is drained.

Due to this: the artwork could have a price of 1 wei, and effectively never be sold again in our lifetimes...

Due to these edge-cases, this artwork should only be bought/sold with extreme caution and deep knowledge of blockchain architecture. It will remain as-is, to continue the experiment.

Massive thanks @JasoonS for finding both these edge-cases and informing me. Check out wildcards.world for more harberger taxed patronage collectibles.

V2:

Due to this, it has been fixed in a new version, along with a whole refactor of the website. It will be released with a price of zero ETH. Ideally, I would like to offer the initial sale to the owner of V1 that has held it for more than a year. If this is you, please get in contact. [email protected] with a signature of ownership over that address.

I will release the new version not sooner than Friday 19 June 2020.

[x5engine]

love it but how would you handle the high gas price?

[scottfits]

hi @simondlr - i know its been a while on this issue but question for you. i just released a Harberger implementation at calendar.org that lets you own calendar days and am worried about the Blocking Sale bug. Am I correct in saying that .send() fails silently, so will not in fact revert?

I see you solved this by holding some funds in escrow in V2 if a contract reverts but i didn't set that up.

I think in my current implementation, anyone who buys from a contract that reverts will simply not get paid, but the item will not be locked forever. Curious if you think my analysis is correct

[simondlr]

Hey @scottfits.

.send() fails silently, yes. I checked your code (the relevant part), and yes, this is only a problem for the owner. If they used a contract to buy it without being able to handle a send(), they won't receive the returns from the sale. So, those funds will get stuck in the contract, but I don't think it would cause other problems.