Chasing the DAO Attacker’s Wake – A second exploit • Hacker News Board

Re: Chasing the DAO Attacker’s Wake – A second exploit

#71

Post by stcredzero » Tue, Jun 21, 2016, 4:43 PM UTC

heliumcraft wrote: post #60

cel1ne wrote: post #48

So what they should have implemented is communicating sequential processes / actors instead of arbitrary calls. The more I read about ethereum's technical details, the more it sounds like a joke to me.

It's a code mistake by who did the DAO code. (DAO != Ethereum) It's more the equivalent of using eval in your nodejs code to evaluate some parameter received from a user. It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.

It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.

But if you're setting up a situation where server after server is constantly compromised because of hard to discern reasons, then yes, that is a bad idea. Having an internet is something as obviously good as electrical wiring and highway bridges. Having a badly implemented internet is as obviously bad as faulty wiring and badly engineered highway bridges.

This stuff is making Ethereum sound like it was written by people as unqualified to make such a system as a dev who would use eval in nodejs code on a user supplied string is to implement an ecommerce site.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#72

Post by drcode » Tue, Jun 21, 2016, 4:43 PM UTC

vessenes wrote: post #64

bouk wrote: post #15

Seems like this is what mutexes were invented for

The typical solidity dev is "but mutexes cost so much gas!" There's an optimization problem not yet sorted out here. If I were king of ethereum, (happily I'm not), I'd make a very cheap mutex support part of the eth vm and encourage solidity and serpent devs to use it as needed.

I suspect we'll see something like mutexes in the next ethereum EVM revision.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#73

Post by cel1ne » Tue, Jun 21, 2016, 4:46 PM UTC

heliumcraft wrote: post #18

"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)." No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.

So you think it's safer if used among "trusted contracts"?

Even if you wrote all the contracts that are interacting like this yourself, this is an immense source for bugs. As anyone with some experience in concurrent programming or OOP can tell you.

Communication between contracts should have been defined and done via channels.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#74

Post by curiousgal » Tue, Jun 21, 2016, 4:46 PM UTC

drcode wrote: post #69

heliumcraft wrote: post #18

"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)." No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.

Yeah, all this shadenfreude from people who (wrongly) predicted ethereum would never work, and who want to feel vindicated, is predictable but frustrating.

Honestly, I was in awe by r/bitcoin's reaction to this whole DAO debacle. I thought that the whole Mt Gox "incident" has taught them some empathy to people losing money but I was very wrong.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#75

Post by drcode » Tue, Jun 21, 2016, 4:47 PM UTC

alfiedotwtf wrote: post #3

Animats wrote: post #2

So one contract can call a function in another contract, in the middle of their transaction: if (_recipient.call.value(_amount)()) { // vulnerable That's inherently a scary feature, and it was exploited. Etherium's "Solidity" suffers from the desire to have it be a general-purpose computer. It should have been if-then rules, or a logic tree, or a decision logic table - a finite representation of business logic subjec…

> At least we found out early that this isn't going to work. $US150M later isn't early

Meh, the money is going to likely be routed back to the original owners via a fork.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#76

Post by mbrock » Tue, Jun 21, 2016, 4:47 PM UTC

jerf wrote: post #58

mbrock wrote: post #12

I don't understand "you can't assume anything about the state of the contract." Surely the contract's state is only modified by the contract's own code, which means you can assume that the state is not altered arbitrarily but only according to the rules set up by the contract. Yes, you need to be careful about external calls that make altering calls to you.

The problem pointed out in this article isn't that it is impossible to write correct contracts. The problem is that it means that it is superhumanly difficult to write correct contracts, using the current feature set and infrastructure. This is especially true in what is theoretically an actively hostile environment, which the DAO hack proves is also actually an actively hostile environment. It is theoretically possi…

I'm not sure that it is super humanly difficult. It seems likely that programming patterns, such as not using I trusted external sends at all, will emerge that any contract will need to abide by to be trusted.

If what you say is true then Ethereum is DOA, which seems unlikely to me. (I don't own any ETH.) I totally agree that it would be great to have more language based security and I've started dabbling with some stuff myself (playing with verified byte code compilation in Agda) but my basic attitude is that worse is better, these hacks are unfortunate but educational, and now we're going to see way more care in contract construction and let's hope it works out.

It might be that Solidity is going to be replaced, and it's super interesting what will come. A bunch of people are insisting that some variant of functional programming with types is necessary for correct contracts but I'm skeptical until I see an actual proposal...

Re: Chasing the DAO Attacker’s Wake – A second exploit

#77

Post by drcode » Tue, Jun 21, 2016, 4:49 PM UTC

mjfl wrote: post #44

homakov wrote: post #41

Earlier quoted context omitted.

This is unfair to banish a company for not having enough "security experience". It could happen to anyone (i mean making such a design mistake), plus they afaik had some external audits. "Aha, no security background!" is wrong.

It is absolutely fair to banish a company for security credentials if it's dangling $150 million out in the open air.

> if it's dangling $150 million out in the open air.

The ethereum foundation didn't do this, the slock.it team is a separate group responsible for this bug.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#78

Post by IncRnd » Tue, Jun 21, 2016, 4:50 PM UTC

Solidity is to Solid as Oracle is to Unbreakable.

These really are solved problems.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#79

Post by homogeneous » Tue, Jun 21, 2016, 4:51 PM UTC

With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world.

Even something as trivial as betting on sports requires deference to a trusted authority to say "this team won". What advantages does an ethereum smart contract provide over, say, some kind of trusted bitcoin escrow site?

Re: Chasing the DAO Attacker’s Wake – A second exploit

#80

Post by cheeze » Tue, Jun 21, 2016, 4:51 PM UTC

DennisP wrote: post #30

As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last. I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them…

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous, given what is at stake when a bug is included in a contract.

Is there any form of auditing that contracts can go through to not have these pitfalls?

I wonder how many of them are still undiscovered...