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

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

#21

Post by freedaemon » Tue, Jun 21, 2016, 4:02 PM UTC

lostmsu wrote: post #14

Potential vector of attack to look for, not an exploit. Thus, flagged.

It's an exploit because you can do this live on the DAO (and potentially other deployed contracts) today.

Vector of attack for future contracts but already impacts the DAO.

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

#22

Post by nugget » Tue, Jun 21, 2016, 4:02 PM UTC

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.

Well in theory couldn't any obscure exploit in the underlying framework (Solidity or related) be used to exploit contracts based on it? I think a comment from yesterday nailed it - that a system like this may be perfect for processing a repetitive, high volume of relatively low value contracts, wheres high value contracts may be better served by traditional systems wherein the Courts provide dispute resolution as needed. Broadly it would seem like Ethereum needs to isolate the potential for loss due to zero day exploits such that it is less than the savings realized from operational efficiency.

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

#23

Post by niftich » Tue, Jun 21, 2016, 4:04 PM UTC

This reads a little sensational. The original source [1] referred to in the article looks at the issue in more detail.

[1] http://pdaian.com/blog/chasing-the-dao-attackers-wake/

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

#24

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

goldenkey wrote: post #19

lostmsu wrote: post #14

Potential vector of attack to look for, not an exploit. Thus, flagged.

I guess you own some Ethereum and have no shame.

I'd love if we could keep HN free of these boring accusations of shilling. It makes the Reddit cryptocurrency forums really tedious to follow.

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

#25

Post by goldenkey » Tue, Jun 21, 2016, 4:05 PM UTC

woah wrote: post #17

None of these "exploits" really sound much more dramatic than using a database without transactions

Actually it's much worse, it's the equivalent of calling a function that ends up doing something totally different than you thought it would. Very reminiscent of a web bug that has since been blocked by newer browsers: parsing JSON data that ends up using a constructor redefinition exploit to execute arbitrary JS.

Pretty much this: http://www.thespanner.co.uk/2011/05/30/json-hijacking/

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

#26

Post by JulianMorrison » Tue, Jun 21, 2016, 4:08 PM UTC

Isn't this just a normal data race with stateful actors? Something modified the data while A is calling B (doesn't have to be B, could be any X) in between a call and its response.

The answer to this is that mutation needs to be kept under control. Immutable data structures in mutable buckets. Locking around the data that mustn't change. Deep copy all state before calling out. And so forth.

This is basically an understood problem and I'm a bit appalled that Ethereum didn't build protection against it into their design.

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

#27

Post by HoopleHead » Tue, Jun 21, 2016, 4:09 PM UTC

Every article I see on etherium mentions the DAO. Not one of them explains what it means.

Gotta love unexplained acronyms!

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

#28

Post by JulianMorrison » Tue, Jun 21, 2016, 4:11 PM UTC

bouk wrote: post #15

Seems like this is what mutexes were invented for

With a mutex, an A -> B -> A call would deadlock if the mutex is the stop-and-wait or spin-and-retry sort. It would have to be a succeed-or-exception mutex, which is not a common design.

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

#29

Post by heliumcraft » Tue, Jun 21, 2016, 4:11 PM UTC

AJ007 wrote: post #20

Nearly a year ago I made the comment -- "Who are these people[1] and what credentials do they have to build and run a cryptocurrency platform?" [1] https://angel.co/ethereum-1 Today, not a single cryptographer, mathematician, or anyone with software security experience is listed on the Ethereum Foundation member list[2]. I am not attacking any individuals by themselves, but as a group this says a lot. For the record,…

you are looking at a page listing boards and advisors, of course those wouldn't be the technical people. Look at the core teams behind the different tools (too many to list here quickly), as well as the devs working in companies in the ecosystem such as consensys and ethcore, they are all quite qualified and smart people. Two examples come to mind are vlad zamfir and Dr. Christian Reitwiessner.

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

#30

Post by DennisP » Tue, Jun 21, 2016, 4:11 PM UTC

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 call a withdraw function.)