A breach has been identified and manipulated in the DAO, and the perpetrator is presently engaged in siphoning the ether within the DAO into a subsidiary DAO. The breach is a recursive calling flaw, where the assailant invokes the “split” function, and then recursively calls the split function within itself, thus accumulating ether multiple times in a single transaction.
The siphoned ether resides in a subsidiary DAO at https://etherchain.org/account/0x304a554a310c7e546dfe434669c62820b7d83490; even if no steps are taken, the perpetrator will not be able to retrieve any ether for approximately another ~27 days (the creation period for the subsidiary DAO). This is an issue that specifically impacts the DAO; Ethereum itself remains completely secure.
A software fork has been suggested, (with NO ROLLBACK; no transactions or blocks will be “undone”) which will make any transactions that perform any calls/callcodes/delegatecalls that decrease the balance of an account with code hash 0x7278d050619a624f84f51987149ddb439cdaadfba5966f7cfaea7ad44340a4ba (i.e., the DAO and its subsidiaries) resulted in the transaction (not just the call, but the transaction) being rendered invalid, starting from block 1760000 (exact block number may vary until the code is released), preventing the ether from being withdrawn by the perpetrator beyond the 27-day period. This will allow ample time for deliberation on potential additional measures, including enabling token holders to retrieve their ether.
Miners and mining pools should proceed to permit transactions as usual, await the soft fork code, and be prepared to download and implement it if they consent to this direction for the Ethereum ecosystem. DAO token holders and Ethereum users should remain patient and composed. Exchanges should feel confident in resuming ETH trading.
Contract creators must be cautious to (1) be extremely vigilant regarding recursive call defects, and heed advice from the Ethereum contract programming community that will likely arise in the coming week on alleviating such flaws, and (2) avoid developing contracts that contain over ~$10m in value, except for sub-token contracts and other systems whose value is defined by social agreement external to the Ethereum platform, which can be seamlessly “hard forked” through community consensus if a defect arises (e.g., MKR), at least until the community acquires more experience in bug management and/or improved tools are established.
Developers, cryptologists, and computer scientists should recognize that any high-level resources (including IDEs, formal verification, debuggers, symbolic execution) that facilitate the creation of secure smart contracts on Ethereum are ideal candidates for DevGrants, Blockchain Labs grants and String’s autonomous finance grants.
This post will be continually updated.