CRITICAL UPDATE Re: DAO Vulnerability

An attack has been found and exploited in the DAO, and the attacker is currently in the process of draining the ether contained in the DAO into a child DAO. The attack is a recursive calling vulnerability, where an attacker called the “split” function, and then calls the split function recursively inside of the split, thereby collecting ether many times over in a single transaction.

The leaked ether is in a child DAO at https://etherchain.org/account/0x304a554a310c7e546dfe434669c62820b7d83490; even if no action is taken, the attacker will not be able to withdraw any ether at least for another ~27 days (the creation window for the child DAO). This is an issue that affects the DAO specifically; Ethereum itself is perfectly safe.

A software fork has been proposed, (with NO ROLLBACK; no transactions or blocks will be “reversed”) which will make any transactions that make any calls/callcodes/delegatecalls that reduce the balance of an account with code hash 0x7278d050619a624f84f51987149ddb439cdaadfba5966f7cfaea7ad44340a4ba (ie. the DAO and children) lead to the transaction (not just the call, the transaction) being invalid, starting from block 1760000 (precise block number subject to change up until the point the code is released), preventing the ether from being withdrawn by the attacker past the 27-day window.This will provide plenty of time for discussion of potential further steps including to give token holders the ability to recover their ether.

Miners and mining pools should resume allowing transactions as normal, wait for the soft fork code and stand ready to download and run it if they agree with this path forward for the Ethereum ecosystem. DAO token holders and ethereum users should sit tight and remain calm. Exchanges should feel safe in resuming trading ETH.

Contract authors should take care to (1) be very careful about recursive call bugs, and listen to advice from the Ethereum contract programming community that will likely be forthcoming in the next week on mitigating such bugs, and (2) avoid creating contracts that contain more than ~$10m worth of value, with the exception of sub-token contracts and other systems whose value is itself defined by social consensus outside of the Ethereum platform, and which can be easily “hard forked” via community consensus if a bug emerges (eg. MKR), at least until the community gains more experience with bug mitigation and/or better tools are developed.

Developers, cryptographers and computer scientists should note that any high-level tools (including IDEs, formal verification, debuggers, symbolic execution) that make it easy to write safe smart contracts on Ethereum are prime candidates for DevGrants, Blockchain Labs grants and String’s autonomous finance grants.

This post will continue to be updated.