From reading the article on Smart Contract security (https://blog.ethereum.org/2016/06/10/smart-contract-security...), I get the feeling that the programming model might be somewhat to blame. The "obvious" ways of implementing something are subtly broken, in ways that are very difficult to anticipate without a very deep understanding of the protocol. The programming model demands that the program be capable of calling functions that are not under the programmer's control, and which can do nearly anything. This is very, very difficult to get right, and very easy to screw up, as anyone who has tried to write a sandbox environment can attest to.
This blog post[1] from the Ethereum Team describes the possible attack.
[1]https://blog.ethereum.org/2016/06/10/smart-contract-security...
I guess if Ethereum makes a hard fork, that will damage it much more - basically, it makes the "smart" contracts unenforcable.
address.call.value(amount) and the call being synchronous
you do:
address.call.queue_value(amount) and then at the end of your contract execution it runs the asynchronous calls that have been queued
a lot of the DAO calls (all of them??) to external addresses don't need the result so having an asynchronous transfer primitive would have just solved the problem.
these external callbacks are very dangerous. for example you have function _entry_ call function _logic_ and everything is ok. then someone decides to change function _logic_ to perform an external callback and this breaks the behaviour of function _entry_. when you have this non-local side effects from changes you will create security bugs very easily.
It doesn't "go missing", presumably the hacker will drain it into Bitcoin via any anonymous exchange accounts they have. Everyone loses big time (except the attacker if they manage to launder some of the coins). Watch for a wave of rebranding.
> How severe could this attack be - does it pose an existential threat to The DAO (or Ethereum, more broadly)?
We will see. The group behind TheDAO has a lot of pull - if Ethereum successfully rejects calls for a hard fork that will damage it severely in the public's eye, but will be the ultimate proof of concept.
> How is this attack being perpetrated? Has the attack vector been previously anticipated? Why is this unexpected?
Why, take a look: https://blog.slock.it/no-dao-funds-at-risk-following-the-eth...
Copied:
""" No DAO funds at risk following the Ethereum smart contract ‘recursive call’ bug discovery Our team is blessed to have Dr. Christian Reitwießner, Father of Solidity, as its Advisor. During the early development of the DAO Framework 1.1 and thanks to his guidance we were made aware of a generic vulnerability common to all Ethereum smart contracts. We promptly circumvented this so-called “recursive call vulnerability” or “race to empty” from the DAO Framework 1.1 as can be seen on line 580: // we are setting this here before the CALL() value transfer to // assure that in the case of a malicious recipient contract trying // to call executeProposal() recursively money can’t be transferred // multiple times out of the DAO p.proposalPassed = true; Three days ago this design vulnerability potential was raised in a blog post which subsequently led to the discovery of such an issue in an unrelated project, MakerDAO. This was highlighted in a reddit post, with MakerDAO being able to drain their own funds safely before the vulnerability could be exploited. Around 12 hours ago user Eththrowa on the DAOHub Forum spotted that while we had identified the vulnerability in one aspect of the DAO Framework, the existing (and deployed) DAO reward account mechanism was affected. His message and our prompt confirmation can be found here. We issued a fix immediately as part of the DAO Framework 1.1 milestone. The important takeaway from this is: as there is no ether whatsoever in the DAO’s rewards account — this is NOT an issue that is putting any DAO funds at risk today. """