Slock.it Blog

Ah yes, what you describe is what Christoph Jentzsch dubbed the Universal Sharing Network, or USN. Slock.it [recent round of seed funding](https://blog.slock.it/slock-it-secures-2-million-usd-seed-funding-to-b… is dedicated to its development. We're really lucky to have some amazing partners such as [Canonical](https://www.canonical.com/) to help bring this to life. We expect the first integrations to make their way to the general public during the course of 2018, with some private betas kicking off Q3-Q4 this year.

The DAO code was reviewed [1] by the best security audit company in the world [0] and was/is made from irrefutable computer code [0]. [0] https://slock.it/dao.html [1] https://blog.slock.it/deja-vu-dao-smart-contracts-audit-results-d26bc0…

- I don't think there's any definitive details yet, but it could be an instance of this attack [1]. The code behind the DAO is available here [2]. Apparently [3], there's a bug where one can recursively call `splitDAO` multiple times to extract ether from the contract if one has a split open. - Ether can go missing when it is sent to a public address which has no known corresponding private key. It's a "we can't inverse a hash" type of problem. - People lose if they're holding a long position on ETH, or have DAO which they can now no longer recoup to ETH. People gain if they're shorting ETH, or are the attacker themselves (it looks like the ETH from the dao is going to this address [4]) - Looks to be an existential threat to the DAO from where we're standing right now. I can't see any mitigations but an entire Ethereum blockchain split. [1] https://blog.slock.it/no-dao-funds-at-risk-following-the-ethereum-smar… [2] https://github.com/slockit/DAO/blob/develop/DAO.sol [3] http://pastebin.com/DykumjLs [4] http://etherscan.io/address/0x304a554a310c7e546dfe434669c62820b7d83490

It's a reentry bug - native ETH always calls the recipient contract's code on transfer, which can call back into the current function. If you manage native ETH do accounting in the wrong order, you can "withdraw" multiple times. 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-ethereum-smar… 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…

https://blog.slock.it/share-charge-smart-contracts-the-technical-angle… has some details on how Share&Charge uses Ethereum blockchain as a transaction layer

The code at that location in the Ethereum blockchain implements a Decentralized Autonomous Organization that takes Ether from participants in exchange for tokens granting them the right to vote on proposals for this specific DAO to fund and the right to receive any benefits from the execution of funded proposals. This is the primer to the how it is supposed to work: https://blog.slock.it/a-primer-to-the-decentralized-autonomous-organiz… Here is how it was attacked: http://vessenes.com/deconstructing-thedao-attack-a-brief-code-tour/

Audits aren't that useful, the DAO was 'audited' soon after creation and none of its flaws were found: https://blog.slock.it/deja-vu-dao-smart-contracts-audit-results-d26bc0…

You would need to submit a proposal. Here is a good overview on that. https://blog.slock.it/how-to-create-gorgeous-proposals-81eb3f606226#.q…

Slock has responded to this by creating a proposal to fix these security issues: https://blog.slock.it/slock-it-security-proposal-1-is-now-verified-we-…

Pretty close; there's already a $1.5M proposal around securing The DAO: https://blog.slock.it/dao-security-a-proposal-to-guarantee-the-integri…

My guess at how the attackers are doing it: They are calling splitDAO: https://github.com/slockit/DAO/blob/develop/DAO.sol#L618 splitDAO calls withdrawRewardFor which ends up calling back into the users contract. https://github.com/slockit/DAO/blob/develop/DAO.sol#L686 withdrawRewardFor(msg.sender); // be nice, and get his rewards totalSupply -= balances[msg.sender]; balances[msg.sender] = 0; paidOut[msg.sender] = 0; the state is modified after the callback in particular the balances variable. however, earlier in the function it moved funds to a new dao based on the balances variable. // Move ether and assign new Tokens uint fundsToBeMoved = (balances[msg.sender] * p.splitData[0].splitBalance) / p.splitData[0].totalSupply; if (p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender) == false) so presumably an attacker can call splitDAO and then recursively call splitDAO and the funds will be transferred twice. there is also some complications around rewardToken because this state is modified before the callback but apparently it is all zero at the moment. if this is the bug the attackers are exploiting then maybe if they generated rewards it would stop the drain of funds. however, the fact the draining is still going on and the DAO people are likely to know how they are doing it and it hasn't been stopped reduces my confidence that this is how the attackers are doing…