Chasing the DAO Attacker’s Wake – A second exploit

It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous, given what is at stake when a bug is included in a contract.

Is there any form of auditing that contracts can go through to not have these pitfalls?

I wonder how many of them are still undiscovered...

If this code style is an absolute requirement for the code not to be exploited, it should be probably be built-in in the language specification itself.

Patchwork solutions won't cut it. "Solidity" is inherently unsuited for the task of safe and correct contract design.

What's your setup to mess around with contracts?

> this problem can be completely avoided if every method has no more than one external call and always puts it last.

Actually, it's a bit more nuanced than that. If you have methods that make external calls--even if it's the last thing they do--you still have to ensure that all your externally-callable methods do not share state with the methods that make external calls. Restricting where and how often you do your external calls isn't sufficient, since that last external call at the end of your method can turn around and call other methods in your contract (which can alter the contract's state, if you're not careful).

EDIT: clarification

> At least we found out early that this isn't going to work.

$US150M later isn't early

The problem with a redesign is that the only way you're going to get a reliable design involves a lot of formal verification, which is a rare skill and time-consuming to perform.

Whereas the cryptocurrency space is a startup environment: there's huge pressure to launch first so that you can get the money that people are begging to throw into untested speculative finance systems. And the refusal to countenance human control or any of the normal forms of accountability - these things are designed out of the system deliberately - means that there's going to be a long, slow, expensive period of designing them back in.

Yeah, all this shadenfreude from people who (wrongly) predicted ethereum would never work, and who want to feel vindicated, is predictable but frustrating.

So you think it's safer if used among "trusted contracts"?

Even if you wrote all the contracts that are interacting like this yourself, this is an immense source for bugs. As anyone with some experience in concurrent programming or OOP can tell you.

Communication between contracts should have been defined and done via channels.

So it impacts the DAO and potentially impacts other deployed contracts (we don't know yet).

It's an issue with Solidity because it doesn't even do static analysis to give the programmar a warning.

It's not that programmers actively avoid doing this or are explicitly warned to not do it. When real money is at stake the language design needs to be a lot more careful.

Unfortunately, worse is better.

It's not quite a data race, since there's nothing parallel at all. Transactions are put in a particular order and run one at a time. So it actually does have to be B that does the modification.

One easy solution is to have just one external call per method, and always put it at the end of the method. Another is to use a single mutex for all public functions of the contract, so any callbacks fail.

Well in theory couldn't any obscure exploit in the underlying framework (Solidity or related) be used to exploit contracts based on it? I think a comment from yesterday nailed it - that a system like this may be perfect for processing a repetitive, high volume of relatively low value contracts, wheres high value contracts may be better served by traditional systems wherein the Courts provide dispute resolution as needed. Broadly it would seem like Ethereum needs to isolate the potential for loss due to zero day exploits such that it is less than the savings realized from operational efficiency.

The problem pointed out in this article isn't that it is impossible to write correct contracts. The problem is that it means that it is superhumanly difficult to write correct contracts, using the current feature set and infrastructure. This is especially true in what is theoretically an actively hostile environment, which the DAO hack proves is also actually an actively hostile environment.

It is theoretically possible to call out to another contract that has the ability to make further calls safely... but how can you be sure you've done it safely?

This isn't a unique problem. It arises in imperative-based programming all the time. But what in Javascript may be a bit of a coding error that means the next page of search results didn't load this time, in Solidity it means you may lose your shirt.

Also, I'd suggest that after-the-fact "static analysis" tools don't help. It's basically the same situation that real-world computer security is in, and right now, that world is massively advantage attacker, with generally far less direct incentive to attack than a blockchain functioning directly as money does. If the static analysis tool is open enough for "everyone" to use, the attackers get to use it too, and they can use it on all contracts at once because they're all open, and they have all the motivation to do so before the proper contract owners have time to fix their contracts. Every time the static analysis tools release a new check, it's an advantage-attacker race between exploiting the new check and fixing the contracts. The attackers are going to win big, repeatedly.

A Turing-complete blockchain needs to come out of the gate nearly 100% correct on this front, just as it needs to come out of the gate nearly 100% correct on the encryption security.

In the scenario you gave, the trusted oracle never needs access to the funds. This is important for legal/regulatory reasons. This would not be possible without smart contracts.

Yes, its not 100% trustless, but its far more trustless than the alternative.

Some simple use cases:

- a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen.

- payment schedules or any kind of transaction that does not function exactly like a one time, full size payment (payments, debt, etc).

- more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked

In all of the above the inputs are contained in the blockchain and therefore have no need for trusted oracles.

I think the basic idea is that with Bitcoin, you sort of have to hack at it to achieve any unintended functionality. These things can and do exist in the Bitcoin world, but when you get down to it, Bitcoin is meant to be a currency; anything built on top of that is just a hack that happens to work. Ethereum and its smart contracts, on the other hand, are structured to handle these sorts of extensions by design. There's nothing that Ethereum can do that Bitcoin absolutely can't be used for in some hacky way AFAIK, but it's generally much easier to do complex things with Ethereum that aren't strictly transactions of currency.

Contracts I'm working on include variants of anti-theft vaulting, blind auctions, crowdfunding, person-to-person gambling, currencies, exchanges, and a simple implementation of Bitcoin's Lightning. None of them require external data.

For those contracts that do, at least you're reducing the third-party trust to "provide accurate data" instead of "hold my funds without stealing them." To reduce trust in a single entity you can use various schemes that allow multiple independent parties to provide the data.

Ethereum (well, Solidity) calls them methods, not functions, and everybody agrees that methods are potentially state changing procedures.

Moreover, there is a staggering amount of precedence for using "function" without implying purity, so even if Solidity did call them functions, that would be entirely normal terminology.

And, well, the entire point of invoking a contract is to effect some change to the state of the blockchain, so it would be strange to expect that Solidity methods were pure functions.

Well, solidity is kinda javascript-style syntax and that's the keyword from javascript.

On a pedantic level, you're absolutely correct, but real-world usage generally makes 'function' equivalent to 'subroutine', hence why we have the specific term pure function to disambiguate.

No - a pure function is a function that has no side-effect (other than heat loss).

You are talking about referential transparency. Even functions that are not pure can be referentially transparent.

as long as eveyone agrees :)

There was a 3K BTC worth short position right before the attack.

How did you manage to post emoji? I thought HN stripped those (somewhat overzealously…)

Actually it's much worse, it's the equivalent of calling a function that ends up doing something totally different than you thought it would. Very reminiscent of a web bug that has since been blocked by newer browsers: parsing JSON data that ends up using a constructor redefinition exploit to execute arbitrary JS.

Pretty much this: http://www.thespanner.co.uk/2011/05/30/json-hijacking/

With a mutex, an A -> B -> A call would deadlock if the mutex is the stop-and-wait or spin-and-retry sort. It would have to be a succeed-or-exception mutex, which is not a common design.

The typical solidity dev is "but mutexes cost so much gas!"

There's an optimization problem not yet sorted out here. If I were king of ethereum, (happily I'm not), I'd make a very cheap mutex support part of the eth vm and encourage solidity and serpent devs to use it as needed.

Yeah, but they seem to be awfully reluctant to pay out on it.

It's a code mistake by who did the DAO code. (DAO != Ethereum) It's more the equivalent of using eval in your nodejs code to evaluate some parameter received from a user. It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.

It means "Decentralized Autonomous Organization".

It's usually used as a common term ("I'm creating a DAO"), but these guys called theirs "The DAO". This attacker exploited "The DAO".

Doubleclick drag rightclick search on Google.

Here, I googled it for you https://daohub.org/

Okay, so let me preface this with a warning. This will be an imprecise analogy! This is just meant to be an aid to understanding. Obviously, there are nuances of the DAO that don't fit perfectly into this model.

Imagine a publicly owned company. It has a CEO, COO, CFO, board, and shareholders. Most decisions are made by the chief officers of the company, and these officers are kept in check by the board of directors. Some shareholders can vote on certain decisions as well if they have the right kind of stock, but for the most part, consensus isn't really needed for most decisions. Day to day operations are handled by the COO, finances are handled by the CFO, and the CEO sort of steers the company as a whole. Most of the time, the board is hand picked to make sure that this centralization of power remains intact. In most companies, shareholders exist primarily to cash in on their own stake in the company either through dividends or by eventually selling their stock. They don't really have to make decisions most of the time, they just provide the capital. The board is there to make sure that their best interests are being catered to basically.

The DAO is almost as if you got rid of management entirely. With the DAO, you have a distributed consensus platform for all shareholders to participate in. Decisions are made democratically through a proposal system ("Should we invest x amount of Ether into y?"), and regulated semi-autonomously by Ethereum contracts. I say semi-autonomously because there is a sort of "board of directors" that takes proposals and filters them out to make sure that a) there aren't too many proposals to be voting on, and b) all the proposals to be voted on are reasonable. You can also split off your stake in the DAO into a smaller DAO if you feel your voice isn't being heard or you don't like the direction the current DAO is going. This is what was attacked the first time IIRC.

There's a whole lot more to it of course, but that's basically how I understand it.

Agreed the original article does a great job. However, without the "sensational" title and simpler explanation people were not paying proper attention to this.

The original article discussed a bunch of other things as well -- everyone should read it to understand the details.

Ok, we changed the url to that from https://blog.blockstack.org/solar-storm-a-serious-security-e..., and added the subtitle (of that post) to make the point clearer.

We also merged the comments from https://news.ycombinator.com/item?id=11934472 here, since there weren't that many of them and they were about the same post.

you are looking at a page listing boards and advisors, of course those wouldn't be the technical people. Look at the core teams behind the different tools (too many to list here quickly), as well as the devs working in companies in the ecosystem such as consensys and ethcore, they are all quite qualified and smart people. Two examples come to mind are vlad zamfir and Dr. Christian Reitwiessner.

just for a point of reference:

https://www.torproject.org/about/board.html.en

granted a few people with the right background, but also a bunch with backgrounds like those you listed.

They've claimed the involvement of Ralph Merkle and Neal Koblitz.

https://twitter.com/IOHK_Charles/status/463794004492951552

https://twitter.com/ethereumproject/status/43337626144945766...

Of course, I haven't seen anything other than those two tweets to indicate their involvement....

This is unfair to banish a company for not having enough "security experience". It could happen to anyone (i mean making such a design mistake), plus they afaik had some external audits.

"Aha, no security background!" is wrong.

You're making the mistake of believing that the CV's of token board or foundation members have anything at all to do with quality, reliability or integrity.

Such beliefs lead to the Appeal to Authority fallacy, and others.

You see a common pattern in crypto projects. The core of the project is passionate autodidacts and the experts are in periphery.

Tor and Ethereum have ample access to experts via academic research, security auditors and academic consultants.

Tor worked hard to build up this pattern by encouraging a robust outsider community to form around Tor. Ethereum has done the same from the get go.

Your comment from a year ago was pretty much entirely wrong: The ethereum platform has so far been stable and without exploits to this date. The exploits of theDAO and the exploits described in the article are smart program exploits, not exploits in the underlying platform.

Could the solidity programming language have some more features to protect inexperience smart contract programmers from themselves? Certainly, nobody is disputing that.

Generally speaking the longer someone has been in a specific field, the lower the probability of them thinking of a new method or agreeing with new things. This is a general pattern across the board with anything ews, startups, projects, etc.

As somebody working with a lot os startups, having somebody with 30 years of a specific core competency on the founding team is a huge red flag.