Associated Incidents
The tragic combination of inevitable bugs and immutable code
Last week witnessed a catastrophic event in the Ethereum ecosystem, when The DAO, a smart contract less than two months old, began rapidly leaking funds to an unknown party. Looking at the current set of Ethereum contracts, filled with casinos and self-declared Ponzi schemes, this might not seem like a big deal. That is, until you learn that over 12 million units of ether, the Ethereum cryptocurrency, had been invested in The DAO by almost 20,000 people. That’s around 15% of all the ether in existence, valued at over $250 million on June 17th.
Two days later, The DAO’s assets dipped below $100 million. Two things contributed to this precipitous fall. First, a third of its funds (as denominated in ether) had already been taken. And second, the resulting panic sent the market price of ether crashing down from its peak of over $21 to a more sobering $10.67. (At the time of publication, the price had recovered to around $14.) This second effect was a natural consequence of the first, since much of ether’s recent increase in value was driven by people buying it to invest in The DAO.
The DAO had promised to act as a new type of decentralized crowdsourcing vehicle, like Kickstarter or Indiegogo but without the middleman and regulation. It was designed to let participants pool their cryptocurrency, collectively vote on projects looking for funding, then invest and reap the future rewards. Before catastrophe struck, over 100 projects had already been proposed, most of which were related to Ethereum itself. In addition, The DAO allowed participants to withdraw their uninvested funds at any time, positioning itself as a low risk investment.
Ironically, the individual or group which drained The DAO did so by exploiting subtle errors in this withdrawal mechanism. Like all smart contracts in Ethereum, The DAO is just a piece of computer code, which is “immutably” (i.e. permanently and irreversibly) embedded in the blockchain and executed by every node in response to incoming transactions. And like any self-respecting smart contract, The DAO provides full transparency by making its source code easily accessible online. This means that anybody can independently verify its functionality but also, crucially, look for vulnerabilities. And yet, the immutable nature of blockchains prevents any such problems from being fixed.
At the end of May, several critical issues were highlighted on the outstanding Hacking Distributed blog, alongside a call for a moratorium on project proposals for The DAO. This is what we might call the ‘white hat’ approach, in which exploits are reported for the good of the community. Nonetheless nobody seemed too worried, as the problems related to skewed economic incentives rather than a risk of outright theft. Simultaneously, however, it appears that others were poring over The DAO’s code with greater self-interest – namely, to look for a way to make a ton of money. And on June 17th, someone succeeded.
Draining The DAO
In a general sense, the attack arose from the interaction between vulnerabilities in The DAO’s code and other code which was designed to exploit them. You see, when looked at in isolation, The DAO did not contain any obvious mistakes, and indeed it was only released after an extensive security audit. But with the benefit of hindsight and many more eyes, a significant number of errors have since been found.
I won’t provide a full technical description of the exploit’s mechanism here, since others have already published superb and detailed post mortems (see here, here and here). But I will explain one particular vulnerability that was present, because it has been discovered in many other smart contracts and serves as an instructive example.
Let’s say that a smart contract holds funds on behalf of a number of users, and allows those users to withdraw their funds on request. The logic for the process might look something like this:
Wait for a user to request a withdrawal. Check if that user’s balance is sufficient. If so, send the requested quantity to the user’s address. Check that the payment was successful. If so, deduct the quantity from the user’s balance.
This all looks eminently sensible, and rather like an ATM which gives you some cash and deducts the appropriate amount from your bank balance.
So how can this simple process go wrong? Well, it turns out that if an Ethereum address belongs to a contract rather than a regular user, then this contract can run some code in response to receiving funds. And this code can, in turn, trigger other pieces of code on the Ethereum blockchain. Crucially, it can even trigger the same piece of code that caused it to be paid in the first place.
This means that, during step 3 above, the receiving address can send a new request for withdrawal, beginning a new process at step 1 before the previous process has completed. Since the user’s balance is only reduced in step 5, a new withdrawal will