The DAO Security

EDIT: this article was originally written and published exactly one week before the DAO hack. I recommend the following to be read in the pre-hack context where no critical security issues were known.

Since “The DAO” launched on the 28th of May there’s been a temporary moratorium in effect following security concerns regarding it’s implementation. One of the first thorough analyses by Dominic Williams lead to debate and further research into how the DAO quorum, splitting and other functions work, eventually sparking a draft paper published by Vlad Zamfir, Emin Gün Sirer et al.

I’m one of the curators of the DAO and have worked with blockchain (security) engineering the last few years. The last few weeks I’ve discussed these concerns with Dominic, Vlad and other developers & researchers in the Ethereum community as well as with the other DAO curators and the Slock.it team. People keep asking me about my opinion and there’s also been requests on the DAO slack for curators to be more active in this regard. Therefore I want to publicly clarify my views on the potential security issues and how I believe they should be resolved.

As a disclaimer I don’t have any DAO tokens because I found the investment potential less exciting compared to other contemporary crypto projects and the price movements of BTC and ETH.

However, I am excited for the DAO as a means to fund good projects, as a social experiment and proof of the disruptive power of Ethereum. The last year I worked closely with Christoph and Lefteris on Ethereum and while we now work on different projects we’re all deeply involved with Ethereum and want projects running on it to succeed.

So let’s go through the issues in the draft paper, discuss their potential impact and what the minimal viable fixes could be.

“The Affirmative Bias, and the Disincentive to Vote No”.

This isn’t really an attack as much as badly designed quorum logic — voting “no” actually can cause a proposal to pass — if “yes” votes remain in majority and the “no” vote raised the quorum to the required value. This is misleading, confusing for non-technical users and can paint the wrong picture in terms of statistics & visualisation of pending votes as it can appear that “yes” votes are leading even if more token holders disagree actually with the proposal — but not voting to show it. This is enough of a problem to warrant an upgrade of the DAO code.

Potential solution: define quorum to be on “yes” and “no” separately and not on their summation.

“The Stalking Attack”

The only way for a token holder to withdraw Ether from the DAO is to make a “split” proposal to create a child DAO containing one’s Ether. As this split is public and can be joined by other token holders, an attacker can commit funds amounting to 53% or more of the child DAO, effectively blocking the victim from withdrawing their funds. While there’s technical difficulties both in performing and preventing the attack, we have seen initiated stalking attacks. While most who have made split proposals have not suffered stalking attacks, it’s enough of problem to be a concern and should be considered in a DAO upgrade.

Potential solution: Redesign the split logic and/or enable plain withdrawals (see below for more concrete remedies).

“The Ambush Attack”

In an ambush, a large investor takes advantage of the bias for DAO users to avoid voting NO by adding a large percent of YES votes at the last minute to fund a self-serving proposal.

In an old school real-life auction, the auctioneer will extend the bidding time every time there’s a new bid. The lack of this is fundamentally what enables the ambush attack. Generalising this concern,

Potential solution: Add a variant of the wait-for-quiet algorithm by Dominic Williams to avoid thresholds by continuously extending the vote deadline on each vote, proportional to the size of each vote and inversely proportional to how close the vote is to a tie at that time.

“The Token-Value Attack”

In a token-value attack, a large investor stands to benefit by driving TDTs lower in value, either to profit from such price motion directly (e.g. via shorts of put options), or to purchase TDTs back in the open market in order to acquire a larger share of The DAO.

What the authors describe as “manipulation” in this attack is in reality just a form of (potentially illegal and/or unethical) market / trading activity. While I’m certainly not condoning the various activities described in the attack, it’s naive to think of them as an attack or indeed anything new — in reality such actions is and has been the state of many markets, especially in crypto where market pairs such as BTCUSD and ETHBTC are notoriously volatile, random and “manipulated” (the degree to which varies widely with each market).

The authors make assumptions about rational market actors and brain states of voting token holders. The history of crypto (trading) demonstrates both rational and irrational behaviour of market actors and it’s largely impossible to know at what proportions these coexist. And as with any attempts at trading, there’s always a bigger fish that would cause this “attack” to backfire and ruin the original attacker.

Potential Solution: None. This is the volatile nature & trading of crypto tokens.

“The extraBalance Attack”

In the extraBalance Attack, an attacker tries to scare token holders into splitting from The DAO so that book value of TDT increases. The book value of TDT increases because token holders who split can not recover any extraBalance, so as more holders split, the extraBalance becomes a larger percentage of the total balance, thus increasing the book value of the TDT.

Again, this “attack” is no different from existing trading / market behaviour in crypto markets. Arguing that asymmetric information and scare tactic is an “attack” and not simply the SNAFU state of crypto markets shows a lack of knowledge of just how controlled these markets are by large actors due to their low market caps. While it is true that the extraBalance balance becomes a larger percentage of total balance after splits, this is public information that may or may not be known to voting token holders when they make their speculative decision on whether to hold on to their DAO tokens.

Potential Solution: None. Authors are recommended to try out crypto trading and read some http://www.zerohedge.com/ to get a feeling for how markets work.

“The Split Majority Takeover Attack”

This attack describes the scenario where an attacker instead of attempting a proposal spending 100% of the DAO’s funds requiring a 53% quorum can make multiple proposals.

The constituents of the voting bloc can achieve their goal of emptying out the fund piecemeal. Fundamentally, this attack is indistinguishable “on the wire” from a number of investment opportunities that seem appealing to a majority.

As described this “attack” amounts to nothing more than the danger present in any type of crowdfunding mechanism, whether it’s kickstarter, VCs or a blockchain DAO. Whatever the mechanism, there is always a way to create fake identities and fool people to part with funds. Tricking both the curators and a large part of the DAO community to spend significant amounts of funds over multiple proposals would be extremely difficult. It would require repeatedly faking of identities and fooling the oracle identity function of the curators, as well as convincing a large part of voting token holders to vote for the proposal. While one could argue this type of risk is more significant in the DAO compared to in classical investing, due to the speed of execution, anonymity of participants and other aspects of blockchain systems, the likelihood of any group pulling this of is negligible.

Potential Solution: None. Authors simply describe the risk present in all forms of investing & (crowd) funding.

“Reward Dilution”

This attack was described on The DAO reddit and is carried out by funding proposals that send back ether to the DAO — causing it to issue new reward tokens diluting rewards for prior token holders who split from the DAO.

While this is indeed a real risk, it’s hard to see it happen in practice as it carries roughly the same difficulty as the previous attack — fooling or corrupting the curators AND getting a proposal past the voters. The authors indeed note this, but do not discuss how likely this is in practice. To me it seems very unlikely and not significant enough to warrant a redesign of the DAO.

“Risk-Free Voting”

(…) the token holder simply votes with his funds as usual, but then, when the voting period is over, calls ‘unblockMe’ and executes a split before the proposal is executed.

This is a timing attack exploiting the ability to unblock tokens after a proposal deadline but before it’s execution. As the authors note it’s not without risk as someone can race the attacker to execute the proposal first. However, there is a real risk here and I do think it warrants patching the DAO code, especially as patching this is easy compared to other discussed fixes.

Potential solution: Keep tokens blocked until executeProposal is called and the proposal is closed, whether the proposal is executed as passed or closed.

“The Concurrent Proposal Trap”

(…) a TDT holder who votes YES on a proposal is blocked from splitting or transferring until the end of the voting period on that proposal. This provides an attack amplification vector, where an attacker collects votes on a proposal with a long voting period, in effect trapping the voters’ shares in The DAO.

A key thing to remember here is that blocked tokens can vote on multiple proposals — they could vote “no” on a proposal that attempts to take advantage of votes being blocked in other proposals. The current disincentive to vote “no” due to the broken quorum logic can increase the risk of this attack, as by voting “no” one may actually help pass a proposal that somehow exploits that tokens are blocked by concurrent proposals. Overall I think the risk of this attack is low, as a proposal exploiting blocked tokens is likely to not be whitelisted by curators nor passed by voters.

Potential Solution: Resolving the quorum issue of voting “no” should decrease the risk of this attack to make it insignificant.

“The Independence Assumption”

A critical implicit assumption in the discussion so far was that the proposals are independent. That is, their chances of success, and their returns, are not interlinked or dependent on each other. It is quite possible for simultaneous proposals to The DAO to be synergistic, or even antagonistic; for instance, a cluster of competing projects in the same space may affect each others’ chances of success and thus, collective returns.

Of course proposals can be interlinked or dependent on each other. This is a general concern in any business venture or investment opportunity and nothing new is explained in this concern.

Similarly, cooperating projects, if funded together, might create sufficient excitement to yield excess returns; evidence from social science indicates that social processes are driven by non-linear systems.

Cooperating projects might yield excess returns? We’d better alert the token holders of this concern, as I’m sure it would be quite upsetting to receive more profits than anticipated.

evidence from social science indicates that social processes are driven by non-linear systems.

I do believe one of the authors spaced out a bit here. http://www.sansbullshitsans.com/

Conclusion

Some of the attacks & concerns discussed are significant enough to warrant an upgrade of the DAO code. In particular, we need to address:

• The disincentive to vote “no”
• The stalking attack and the poor performance of splitting as a means of withdrawal
• The ambush attack

Currently there is a debate whether to upgrade the DAO code itself, or effectively enact changes by having curators enforcing a proposal framework

I find both of these approaches inadequate as currently proposed; the DAO 1.1 upgrade is quite extensive and includes several “nice-to-have” features not strictly necessary for a security upgrade.

And the proposal framework has several fundamental problems:

• Creates additional thresholds . For example, it adds a check for quorum of 20% yes votes and a majority support 2 days before the voting deadline. This effectively pushes the can down the road and simply adds new thresholds that can be gamed by e.g. an ambush attack. The better solution is to make use of continous algorithms that have no hard thresholds.
• Duct-tape approach; instead of upgrading the contract that is actually broken, patch it by countering it’s behaviour in chained contracts.
• Technical debt: the DAO itself will remain broken, which eventually have to be fixed.
• Complexity: Reasoning and auditing the aggregated behaviour of the DAO itself and contracts it funds is harder than analysing only the DAO itself.
• Effectively extends power and responsibility of the curators, by having them only whitelist contracts implementing certain logic.

Due to these problems, I will only support a proposal framework if the community fails to reach consensus (53% quorum) on a security upgrade proposal. My suggestion is that we first propose a smaller code upgrade that limits it’s scope to only the most important security issues.

Proposed code upgrade:

1. Calculate quorum on “yes” and “no” respectively, rather than their summation. This avoids passing a vote by voting “no” (and vice versa). Adjust the required % accordingly.
2. Add a simple variant of the wait-for-quiet algorithm that extends the deadline of a proposal on each vote, proportional to the size of the vote and inversely proportional to how close the vote is to a tie. This resolves the ambush attack and avoids the need for token holders to make additional “pre votes” and avoids creation of additional thresholds. It also extends the deadline more if it’s close to a tie, which is good for hotly contested proposals.
3. Add a new vote type “NO_AND_WITHDRAW_IF_PROPOSAL_PASSES” to allow token holders to signal they will leave the DAO if the proposal passes. This largely resolves the stalker attack as DAO splits will be used less for withdrawals and more for the original intention they where designed for: split the DAO into another direction & fire the curators.
4. Keep tokens blocked until executeProposal is called and the proposal is closed, whether the proposal is executed as passed or closed. This would resolve the timing exploit enabling the “risk-free voting” attack.

I’m not fanatical about the exact details of the above and would support reasonable variants such as allowing plain withdrawals.

It’s worth mention that the above is not hard to implement — several Ethereum developers in the community who are familiar with solidity & the DAO are capable of coding this up in a few hours.

The hard part is in writing good tests covering all edge cases around these changes, and getting enough eyes to review & audit the changes. And of course rally up support in the community to get 53% to vote. Overall I’d estimate it to take a few weeks from initial community consensus to deployment.

Analogous to blockchain hard forks, upgrading the DAO code is a serious endeavour requiring a majority of token holders to agree. This makes it tempting to increase the scope of an upgrade to add in additional feature. While I have a ton of ideas around improving the DAO, I’ll end this post here as an exercise in one of the guiding principles of good software & security engineering: avoid scope creep and focus on the minimal viable changes needed.