
Chasing the DAO Attacker’s Wake – A second exploit - freedaemon
http://pdaian.com/blog/chasing-the-dao-attackers-wake/
======
DennisP
As the article briefly suggests, this problem can be completely avoided if
every method has no more than one external call and always puts it last.

I'm messing around with contracts to do about a dozen different things, and it
turns out to be easy to meet this restriction, as long as I'm willing to
design the UI accordingly. (E.g. don't send money to lots of users in one
step, just update their balances and make them call a withdraw function.)

~~~
cheeze
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...

~~~
DennisP
There's both an active developer community willing to help for free, and
professional auditors you can pay. There are also people talking about a NASA-
style bugs/best practices database at some central location.

People are realizing that this needs to be developed like safety-critical
software, not like fast-moving startup websites. But I would say it's not as
scary as, say, developing software for aerospace or medical applications.

And what really helps is that you can do a lot with very little code. I think
all of my contracts are under five pages. I don't think we're ready for big
complicated contracts, but there's a lot we can do with simple little
contracts.

~~~
sandworm101
Five pages? I thought these things were meant to be shorter than plain-English
contracts. I draft and review contracts daily and five pages is long for basic
things (employment, NDAs, IP transfer etc).

~~~
DennisP
It's software, not really comparable to an English-language contract. Most
software is much bigger than that.

Five pages is an outside estimate, for something like a currency exchange. My
crowdfunding contract is about two pages, and the vault is one.

~~~
dragonwriter
> It's software, not really comparable to an English-language contract.

If the point is to be an alternative to normal, "dumb" contracts, than that is
exactly what it needs to be comparable to.

~~~
sandworm101
He is correct in stating that it is code v. english, apples v. oranges. But I
was under the impression that the whole point of using code was to explain
something in more concrete and definitive terms. If doing so takes more words,
more abstract word, with more oppertunity for bugs and loopholes, then what is
the point?

------
Animats
So one contract can call a function in another contract, in the middle of
their transaction:

    
    
        if (_recipient.call.value(_amount)()) { // vulnerable
    

That's inherently a scary feature, and it was exploited.

Etherium's "Solidity" suffers from the desire to have it be a general-purpose
computer. It should have been if-then rules, or a logic tree, or a decision
logic table - a finite representation of business logic subject to exhaustive
case analysis. Contract executions should have been atomic transactions -
either everything commits, or everything gets rolled back. Stack overflow and
running-out-of-gas terminations are inherently trouble.

Etherium needs to go back into the shop for a redesign. At least we found out
early that this isn't going to work.

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

$US150M later isn't early

~~~
jacquesm
That's called a bug bounty.

~~~
pjc50
I came up with "self-distributing bug bounty piñata" in the last DAO-failure
discussion
[https://news.ycombinator.com/item?id=11921677](https://news.ycombinator.com/item?id=11921677)

~~~
jacquesm
Hehe, that's even better. But it is the essence of the matter. If you put
$100M in a bucket you've just incentivized the worlds bad guys to audit your
production in order to figure out how to open the bucket to get to the loot.

And this goes for all of commerce, which is an important realization: security
is not an all-or-nothing proposition, it is an economic affair. Whatever you
wish to secure, you can expect to expend a reasonably constant fraction of
that on the act of securing it. So if you wish to secure $100M you will have
to do a much better job than if you wish to secure $10M or $1M, just like
you're going to spend more money on the lock for a $1k bike than a $25 junker.

When DOA ended up being over-subscribed they should have _immediately_ yanked
the emergency brake because whatever plans they had would end up being moot by
virtue of storing more money in the bucket than they originally planned.

Their security measures would _by definition_ not have been up to the task
because they had planned to secure a much smaller amount. Either that or they
were ridiculously over-confident.

------
heliumcraft
"This impacts all contracts on Ethereum, not just the DAO. This is an issue
with Ethereum’s JavaScript-like programming language (Solidity)."

No it doesn't, no it's not. It affects contracts that use this functionality
with arbitrary untrusted contracts (which is a bad idea), and most contracts
just don't use this functionality at all.

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

~~~
_98fj
Not at all.

When I discovered ethereum a couple of years ago I thought it was a good idea.
Partly because I was turning similar ideas in my head at the time.

But what I read now sounds like amateurs designed & implemented it. Sorry.

~~~
cheez
And if masters had invented it, no one would be using it.

------
JulianMorrison
Isn't this just a normal data race with stateful actors? Something modified
the data while A is calling B (doesn't have to be B, could be any X) in
between a call and its response.

The answer to this is that mutation needs to be kept under control. Immutable
data structures in mutable buckets. Locking around the data that mustn't
change. Deep copy all state before calling out. And so forth.

This is basically an understood problem and I'm a bit appalled that Ethereum
didn't build protection against it into their design.

~~~
DennisP
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.

------
mbrock
I don't understand "you can't assume anything about the state of the
contract." Surely the contract's state is only modified by the contract's own
code, which means you can assume that the state is not altered arbitrarily but
only according to the rules set up by the contract. Yes, you need to be
careful about external calls that make altering calls to you.

~~~
jerf
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.

~~~
mbrock
I'm not sure that it is super humanly difficult. It seems likely that
programming patterns, such as not using I trusted external sends at all, will
emerge that any contract will need to abide by to be trusted.

If what you say is true then Ethereum is DOA, which seems unlikely to me. (I
don't own any ETH.) I totally agree that it would be great to have more
language based security and I've started dabbling with some stuff myself
(playing with verified byte code compilation in Agda) but my basic attitude is
that worse is better, these hacks are unfortunate but educational, and now
we're going to see way more care in contract construction and let's hope it
works out.

It might be that Solidity is going to be replaced, and it's super interesting
what will come. A bunch of people are insisting that some variant of
functional programming with types is necessary for correct contracts but I'm
skeptical until I see an actual proposal...

~~~
jerf
And there are still people running around who think that writing code based on
threads and semaphores isn't superhumanly difficult and people just need to
Try Harder (TM).

At least when they're wrong, they usually don't lose millions of dollars. (But
only... _usually_.)

I think some people are mentally modeling Ethereum as a sort of hobby thing in
their head when they say things like that. I mean, who cares if my hobby
static-rendering blog platform has a few bugs in it, right? But Ethereum
aspires to be the foundation of an economy. Real foundations of economies have
_billions of dollars_ worth of effort poured into them. While a small set of
particularly brilliant people may produce something that can run in this
environment, Ethereum isn't what it would look like if they did.

I also think that people don't realize that the usual fate of a cryptocurrency
is to die. Bitcoin isn't the first cryptocurrency by a long shot.
Cryptocurrencies in general are not strong, robust things. I think something
_like_ Ethereum is quite likely, but there's no particular reason to believe
we aren't three or four more major fully independent stabs at the problem away
from a stable solution. Ethereum makes Bitcoin look like a homework problem in
comparison; it would almost be beyond belief that we'd get it right the first
time.

~~~
mbrock
I think humans are capable of writing correct programs even in machine code,
it's just tricky and requires some expertise.

I also think the EVM itself allows for other paradigms than Solidity that
might make it easy to create certain kinds of contracts.

And I think worse is better is very powerful, so it wouldn't surprise me if
Ethereum sticks along for a long time, like Bitcoin seems to be doing despite
its flaws.

------
nawitus
"that impacts all of Ethereum"

Well, all of Ethereum smart contracts which are written in Solidity and which
use a "call construct" in a certain way.

------
homogeneous
With all this fuss over ethereum security flaws, can someone explain to me the
practical use case for these smart contracts? I just don't understand where
the benefit comes in. It seems like any type of contract that would be useful
requires a human to qualify the meaning of the terms since these contracts
cannot autonomously measure the state of the world.

Even something as trivial as betting on sports requires deference to a trusted
authority to say "this team won". What advantages does an ethereum smart
contract provide over, say, some kind of trusted bitcoin escrow site?

~~~
DennisP
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.

~~~
homogeneous
> _anti-theft vaulting_

Can you go into more details about this?

> _blind auctions_

Or this? How does the contract ensure that the winner of the auction receives
what they have purchased?

> _crowdfunding_

In what respects beyond simply collecting funds? How does the contract judge
that the terms of the funding are adhered to or ensure that the crowdfunders
receive whatever it is they are entitled to as funders?

> _person-to-person gambling_

Any examples? In my post I gave the example of betting on a sports game but
this requires a trusted 3rd party to officiate the outcome of the game.

> _currencies, exchanges_

These are vague descriptions and these things have already been done by
bitcoin.

I'm not trying to nitpick, but I'm looking for specific practical examples
that demonstrates the potential utility of ethereum.

~~~
DennisP
So this gets into the difference between the rhetoric about smart contracts,
and what they actually do. Obviously a smart contract can't ensure that an
auction winner or crowdfunder gets the item. At best there could be some kind
of reputation system. But to enforce something in the real world, you'd have
to get an actual court involved. The smart contract removes the need to have
an auctioneer running the auction and handling funds, that's all.

But that still means that, for example, when I'm trying to implement a new
variant on crowdfunding, I can write the whole backend in several pages of
code and just publish it, instead of renting servers, administering databases,
signing up with a payment provider and having to comply with its terms of
service.

An example of a vault is this scheme:
[http://hackingdistributed.com/2016/02/26/how-to-implement-
se...](http://hackingdistributed.com/2016/02/26/how-to-implement-secure-
bitcoin-vaults/)

...which some researchers proposed for Bitcoin, saying it'd be "easy" to
implement with a hard fork adding a new opcode. I implemented the same scheme
in a smart contract and it took 20 minutes.

Sports betting needs third-party data, but casino games don't.

~~~
homogeneous
Thanks for the reply. I think I understand what you're getting at.

------
thom_nic
Interesting Ethereum uses the term "function" however in programming we
understand a _pure_ function to be an operation that always returns the same
result given the same inputs.

I don't know anything about Ethereum, but if functions rely on external shared
state then they aren't pure functions, are they?

~~~
mst
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.

------
refulgentis
What if the DAO invested in short-selling Ethereum? 🤔🤑

~~~
curiousgal
There _was_ a 3K BTC worth short position right before the attack.

~~~
pigeons
No, there were 3K BTC worth of short ~positions~ right before the attack.

------
saynsedit
Any code that calls arbitrary callbacks is prone to failure. The context in
which a callback is called matters.

Calling a callback at the end of a method avoids interfering with the caller's
state but ignores the state of the caller's caller.

An ethereum contract will only be tractably analyzable if it avoids
dynamically invoking arbitrary callbacks.

------
woah
None of these "exploits" really sound much more dramatic than using a database
without transactions

~~~
goldenkey
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/](http://www.thespanner.co.uk/2011/05/30/json-hijacking/)

------
int_19h
Given that trust is the single most critical aspect of the entire platform,
why doesn't it use languages (for both the platform, and the contracts),
programs in which can be easily formally verified, and for which tools for
such verification already exists?

------
bouk
Seems like this is what mutexes were invented for

~~~
JulianMorrison
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.

~~~
mbrock
EVM doesn't allow the implementation of a blocking mutex and a "spin-and-
retry" would simply run out of gas.

------
IncRnd
Solidity is to Solid as Oracle is to Unbreakable.

These really are solved problems.

------
unfortunateface
The backers of the DAO selflessly created a $150 million bug bounty for
Ethereum and their Smart Contract - Good for them.

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

------
htns
I'd be interested in knowing how this has been dealt with (or not) before. Was
the problem recognized when designing E?

------
deegles
Will the attacker be able to spend any of the funds?

------
cel1ne
So what they should have implemented is communicating sequential processes /
actors instead of arbitrary calls.

The more I read about ethereum's technical details, the more it sounds like a
joke to me.

~~~
heliumcraft
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.

~~~
stcredzero
_It 's a stupid code mistake, but you wouldn't say the internet is a bad idea
because some website got hacked._

But if you're setting up a situation where server after server is constantly
compromised because of hard to discern reasons, then yes, that is a bad idea.
Having an internet is something as obviously good as electrical wiring and
highway bridges. Having a badly implemented internet is as obviously bad as
faulty wiring and badly engineered highway bridges.

This stuff is making Ethereum sound like it was written by people as
unqualified to make such a system as a dev who would use eval in nodejs code
on a user supplied string is to implement an ecommerce site.

~~~
heliumcraft
Essentially this is the equivalent of a dev mistakely using an eval in the
wrong place in a nodejs code. But all these articles are making it sound like
the Ethereum team created the DAO and this issues affect Ethrereum as whole,
which just isn't true.

~~~
tremon
The way I see it (continuing the simile): if you're writing something as
critical as monetary transactions, _everywhere_ is the wrong place to use eval
in nodejs code. And when you're writing a dedicated language for monetary
transactions, _including eval in your API_ is just as wrong. The last part is
why this issue affects all of ETH.

Solidify is a new language, specifically designed for Ethereum. If the
response to contract issues like this is "but that's a known failure mode,
don't do that", then that signals a problem with the language, not just the
contract code.

~~~
stcredzero
_If the response to contract issues like this is "but that's a known failure
mode, don't do that", then that signals a problem with the language, not just
the contract code._

It also signals a problem with the culture, with respect to the perceived
amount of rigor required by the problem domain.

------
HoopleHead
Every article I see on etherium mentions the DAO. Not one of them explains
what it means.

Gotta love unexplained acronyms!

~~~
mtgx
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".

~~~
crispyambulance
Ok, but you realize that merely listing the words in the acronym does nothing
to explain what it actually is. The whole ethereum "ecosystem" is a radical
and new construct that very few people are familiar with.

Given that, I would even say that the name "Decentralized Autonomous
Organization" is a deliberate, almost satirical, obfuscation.

------
niftich
This reads a little sensational. The original source [1] referred to in the
article looks at the issue in more detail.

[1] [http://pdaian.com/blog/chasing-the-dao-attackers-
wake/](http://pdaian.com/blog/chasing-the-dao-attackers-wake/)

~~~
freedaemon
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.

~~~
curiousgal
By people you mean traders. This sensationalism is utterly unnecessary since
the non-traders involved with Ethereum read the original article and are
capable of understanding it.

------
AJ007
Nearly a year ago I made the comment --

"Who are these people[1] and what credentials do they have to build and run a
cryptocurrency platform?" [1]
[https://angel.co/ethereum-1](https://angel.co/ethereum-1)

Today, not a single cryptographer, mathematician, or anyone with software
security experience is listed on the Ethereum Foundation member list[2]. I am
not attacking any individuals by themselves, but as a group this says a lot.

For the record, what I see listed online today is a: consultant, magazine
founder, a programmer, and a lawyer. On the advisory board a sales person, a
psychologist, a leveraged debt consultant. On the "special advisors" list,
which I have no idea what this means, maybe someone who answered a phone call
a few times, one person with a bunch of business credentials, something
"fintech" related with little explanation, and a tech CEO.

Maybe the Ethereum Foundation doesn't need anyone with deep experience in
cryptography and security?

[2] [https://www.ethereum.org/foundation](https://www.ethereum.org/foundation)

~~~
homakov
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.

~~~
mjfl
It is absolutely fair to banish a company for security credentials if it's
dangling $150 million out in the open air.

~~~
dang
> _What are you talking about?_

Please don't be uncivil. It's damaging to collegial conversation, and it's
against the rules
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)).
Please edit such stuff out of your comments here.

~~~
mjfl
edited.

~~~
dang
Appreciated!

