Live data from Hacker News

Ethereum Contracts Are Going to Be Candy for Hackers

vessenes.com

11–20 of 85 posts

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#11
post #6

This is pretty interesting. So I guess there's a huge opportunity here for grey/black-hatted people to analyse contracts and transactions and spot flaws? Apparently even bitcoin has weaknesses like these, with non-standard transaction scripts that may be easily solvable/stealable for anyone with a bit of insight

In Bitcoin, almost all the people use the same script, so it's enough to review it. (I think the only problem is a small malleability.) And when a big problem is discovered almost all the people will change in a short time.

In Ethereum is more encourage to write smart weird custom contracts, so many people write a custom contract with only one pair of eyes to review it, so it's more probable to find errors.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#12
Don't these contracts existing in a market? If one contract is flawed won't customers flock to another competing one? This would create an incentive for quality control.

Or is the proposed problem that these flaws are unavoidable or too costly to prevent? I could see the high-investment cost being a deterrent for developers to adopt the platform. In general the contract code should be as simple as possible and memory safe.

Either way, the sample reference in the article is not very useful. This is a bad time to be looking for quality as this is extremely early and very much in the experimental stage of the idea. It will, of course, deserve scrutiny when it gets more mature though.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#13
post #9

Earlier quoted context omitted.

1) Well, contracts have balances, true. The people calling the contracts pay for it to run, so the dead terminology is at best imprecise. If the contract pays out 10 ether in .01 ether increments, and never takes any in, then it will be dead once depleted. On the other hand, people calling the contract pay for the cycles to run it, so one wouldn't typically go dead in that way. 2) I'm not an expert on the registrar s…

the 2nd point was to address the fact that the contract can be updated/patched with little if any impact to it's end users. so the new version of the contract gets pushed out, the old one is not in use any longer and just kind of dies off :)

Right, but for a ponzi scheme contract, that's not a great outcome. Or, say, a crypto-currency, one of the sample apps in Ethereum documentation.

Either way, you have a trust problem -- who shall be trusted to transfer out all the value the contract holds?

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#15
post #12

Don't these contracts existing in a market? If one contract is flawed won't customers flock to another competing one? This would create an incentive for quality control. Or is the proposed problem that these flaws are unavoidable or too costly to prevent? I could see the high-investment cost being a deterrent for developers to adopt the platform. In general the contract code should be as simple as possible and memory…

From my review of some of these contracts, even fairly obvious flaws are not being exploited (yet).

So, flaws will become known, and presumably there will be ratings and trust ratings and so on eventually. In the interim, though, some of the flawed contracts moved well over $100k in their first week of existence. That seems worth paying attention to.

I would propose flaws like these are unavoidable, unless you can pay what NASA paid. And remediation techniques should be developed urgently, not at some later date.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#16
post #6

This is pretty interesting. So I guess there's a huge opportunity here for grey/black-hatted people to analyse contracts and transactions and spot flaws? Apparently even bitcoin has weaknesses like these, with non-standard transaction scripts that may be easily solvable/stealable for anyone with a bit of insight

In Bitcoin, almost all the people use the same script, so it's enough to review it. (I think the only problem is a small malleability.) And when a big problem is discovered almost all the people will change in a short time. In Ethereum is more encourage to write smart weird custom contracts, so many people write a custom contract with only one pair of eyes to review it, so it's more probable to find errors.

For sure, but I think there's opportunity/vulnerability in bitcoin too. From the top of my mind I recall reading about people grabbing coins quickly from: bad random number generators in at least android, brainwallets/rainbow-tabley private keys, non-standard script for fun or error to the tune of having to solve "2+2"

A little similar to how bad guys hook onto github feeds and instantly exploit leaked aws keys etc

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#17

Don't lawyers do this to real-life contracts?

First, let me acknowledge that this is a fair question. A bit cynical, perhaps, but fair.

To answer it, no, not like this. Contract law has a lot of humans in it. You are certainly able to sign some contracts with combinations of clauses that can get you, and I've read horror stories at the mega-corp levels about contract clauses interacting unexpectedly and screwing some party or other. But even in those cases, the way they got screwed was by a collection of individually-sensible clauses.

A computer running a contract is by contrast blitheringly stupid. If you write a logic error into your contract that lets a participant suddenly claim all the contracted value by simply, say, sending a bid of 0 as many times as there are participants or something, there's nobody and nothing that will prevent that. If you try that in a human contract, it will be invalidated by some human judge.

Sure, lawyers may write complicated contracts in an attempt to screw the other signatory and they may play complicated games with the clauses, but running contracts as otherwise-unsupervised programs is a whole new level.

Furthermore, just having had a quick scan over the language documentation, it looks to me like a bog-standard imperative mutable language. One that is very young, and with few if any features designed for being used in a high-security environment. It appears to be based on raw event-based programming, a style of programming very easy to mess up and hard to declare and preserve invariants in. It looks like a very dangerous programming language to be trying to write financial contracts in. At least it's not dynamically typed, does seem to avoid excessive coercion, and should be memory safe; it could certainly be worse. But it could be better, too.

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#18
post #9

Earlier quoted context omitted.

1) Well, contracts have balances, true. The people calling the contracts pay for it to run, so the dead terminology is at best imprecise. If the contract pays out 10 ether in .01 ether increments, and never takes any in, then it will be dead once depleted. On the other hand, people calling the contract pay for the cycles to run it, so one wouldn't typically go dead in that way. 2) I'm not an expert on the registrar s…

the 2nd point was to address the fact that the contract can be updated/patched with little if any impact to it's end users. so the new version of the contract gets pushed out, the old one is not in use any longer and just kind of dies off :)

How does one assure the the updated contract only fixes bugs and doesn't change the intent of the original contract?

Re: Ethereum Contracts Are Going to Be Candy for Hackers

#19
I went to a talk with Vitalik Buterin recently where he stated code quality was one of ethereum's biggest threats.

But, there is a market for code quality review too now!

Trustless contracts must at least be audited or they will have no ultimate credibility.

Just because something carries a risk, that is no reason not to adopt it, even try to fix it.

If the authors main point about code quality error rates is the main point, NASA has had far more time and funding and it would not be outputting random / get rich quick games either.

Ethereum has issues, but it is young and has a fantastic support base of enthusiasts.

The original author should have done more research on the roadmap for smart contracts and ethereum.

Post reply on HN