
Ethereum fixes serious “eclipse” flaw - DyslexicAtheist
https://arstechnica.com/information-technology/2018/03/ethereum-fixes-serious-eclipse-flaw-that-could-be-exploited-by-any-kid/
======
josephagoss
A thing I've noticed about cryptocurrency news. The people that are pro
cryptocurrency are often far too optimistic and sometimes are not the most
academic people. However I've also noticed that those that constantly critique
cryptocurrency are often so wrong about their assumptions it's just pointless
reading on. It's so hard to actually get a reasonable discussion about
cryptocurrency.

~~~
dvh
Maybe we should create some discussion system where in order to post you need
proof of expertise (PoE)

~~~
ty_a
Maybe you could count number of Ph.D contributors? I bet Bitcoin has as many
or more than every other project combined.

~~~
infowl
Citation needed. Appeal to authority, with no evidence of competency.

------
rargulati
For those interested, here's the paper:
[https://www.cs.bu.edu/~goldbe/projects/eclipseEth.pdf](https://www.cs.bu.edu/~goldbe/projects/eclipseEth.pdf)

Here's the partial-implementation of Countermeasure 2 in geth:
[https://github.com/ethereum/go-
ethereum/pull/16069](https://github.com/ethereum/go-ethereum/pull/16069)

Of note, this fix is still susceptible to attacks, though still an
improvement:

> Since geth v1.8.0 still allows the attacker to freely craft node IDs that
> land in specific buckets, the partial implementation of Countermeasure 2 in
> geth v1.8.0 means that for a given victim’s table, there can be at most 10
> attacker node IDs associated with each attacker IP address. While this
> improves on the situation prior to geth v1.8.0 (where we could eclipse our
> victim using just one or two IP addresses), it does not raise the bar for
> attackers quite as high as we had hoped.

Still making my way through the paper and the PR to identify other things
fixed. Here's the entire 1.8 release: [https://github.com/ethereum/go-
ethereum/releases/tag/v1.8.0](https://github.com/ethereum/go-
ethereum/releases/tag/v1.8.0)

------
heliumcraft
This wasn't a flaw with Ethereum itself or its protocol, but rather an issue
with one of the its client implementations (go-ethereum), other clients like
Parity, Harmony, etc.. are unaffected.

~~~
UncleMeat
Is there any other field of computer security where this argument is
acceptable? Usable security matters. Ecosystems matter. You cannot put a
boundary somewhere in the middle of what the end user sees and call your
security job done.

When people majorly botch x509 cert validation because the spec is so
monstrously complex _that 's still a problem with x509_.

~~~
dahdum
Ethereum specifically chose to develop around multiple clients to mitigate the
risks of implementation errors such as this. It would be ideal if all were
perfect from the start, but no software is, security or otherwise.

------
dlubarov
Isn't relying on IP diversity as a measure of attack difficulty a bad
assumption in the first place? If an attacker has access to the cable outside
my home, then they can pretend to control as many IPs as they want.

It seems to me that the most reliable defense against eclipse attacks is to
just compare the block rate of the longest chain we know about to the
historical average. If the block rate is roughly normal, then either we're
seeing the real longest chain, or an attacker has acquired nearly 50% of hash
power, which is unlikely.

The same idea works with proof of stake -- if the participation rate drops
substantially below the historical average, we're probably not seeing the main
chain, and we shouldn't consider anything final until the participation rate
return to normal.

~~~
EthanHeilman
> Isn't relying on IP diversity as a measure of attack difficulty a bad
> assumption in the first place? If an attacker has access to the cable
> outside my home, then they can pretend to control as many IPs as they want.

If an attacker has access to the cable outside your home they have already
won, it's game over.

>It seems to me that the most reliable defense against eclipse attacks is to
just compare the block rate of the longest chain we know about to the
historical average. If the block rate is roughly normal, then either we're
seeing the real longest chain, or an attacker has acquired nearly 50% of hash
power, which is unlikely.

Block creation have high variance. Over short periods of time, say a few hours
no blocks being announced is fairly common. Over long periods of time how do
you know the mining power has not decreased or increased at a slow rate than
your person prediction.

>The same idea works with proof of stake -- if the participation rate drops
substantially below the historical average, we're probably not seeing the main
chain, and we shouldn't consider anything final until the participation rate
return to normal.

Interesting you can design PoS systems such that if not a quorum of stake is
online, no new blocks are created. Algorand has some very neat properties in
this regard.

~~~
dlubarov
> If an attacker has access to the cable outside your home they have already
> won, it's game over.

Not if I'm looking at the block times or PoS participation rates. The attacker
can feed me their own fork while preventing me from seeing the actual highest-
difficulty chain, but their fork will be suspiciously weak, so I'll know not
to trust it.

> Block creation have high variance. Over short periods of time, say a few
> hours no blocks being announced is fairly common. Over long periods of time
> how do you know the mining power has not decreased or increased at a slow
> rate than your person prediction.

Yeah; with Bitcoin you would need to wait several hours to get a good estimate
of hash power. With more granular blockchains like Ethereum you could get a
good estimate more quickly.

~~~
EthanHeilman
>Not if I'm looking at the block times or PoS participation rates. The
attacker can feed me their own fork while preventing me from seeing the actual
highest-difficulty chain, but their fork will be suspiciously weak, so I'll
know not to trust it.

Would be really interested to read a paper that invents a confirmation
sureness metric based on distances between block times which takes into
account eclipse attacks.

------
panarky
This is an attack on the Kademlia DHT.

Why exactly does Ethereum use Kademlia anyway?

Kademlia's main purpose is to find content distributed among a small
percentage of nodes.

Ethereum doesn't need this, since the entire blockchain is stored on every
node.

And does the attack also work against other applications that use Kademlia,
such as IPFS and I2P?

------
GistNoesis
There are some fun systemic probabilistic attacks based on peer discovery.

One such principle which doesn't need many attacking nodes, rely on peers
self-clustering themselves over time is the following :

You divide the peer network in 2 groups. Using a few number of attacking
nodes, when a peer from one group ask you for a node you know, you answer with
a peer from the same group. Then each peer from each group is more likely to
recommend a peer from the same group. Over time bias accumulate, and cluster
forms, with very few bridges between the two groups which you control.

Obviously it can be mitigated easily by adding some hard-coded "central" nodes
or monitoring the network.

Afaik robust peer discovery in p2p network is still not solved.

------
swang
> The fix for the second attack involved limiting the number of outgoing
> connections a target can make to the same /24 chunk of IP address to 10. The
> changes are designed to make it significantly harder to completely isolate a
> user from other legitimate users.

Maybe it is the way the article is written, or how I've read it, but the
original flaw involved just 2 nodes w/ 2 IP address. This fix sounds like you
need 2 nodes w/ 2 IP addresses that don't have the same /24 octal? Is it that
much more difficult?

> When even a single node presents users with a different version of the
> blockchain, they will be warned of an error that effectively defeats the
> attack.

Doesn't this just mean the attacker has to make sure to control all 13
connections before starting the attack?

------
elmar
the image in the article is really appropriated, the Turing complete VM of
ethereum is a black hole of bugs, on the Genesis, some really bad engineering
decisions were made and probably now is too late to change it.

~~~
heliumcraft
Out of curiosity, what "really bad engineering decisions" are those?

~~~
elmar
My view, of course, every decision as a trade-off, everything i say is
controversial

\- The main ledger and smart contracts should be separated, everyone smart
contract is public, why??

the smart contracts should be run on several specific sidechains. Why if I buy
a crypto kittie everyone as to know and store the transaction for all
eternity.

Wait sharding is coming, yes but will reduce the security guarantees.

~~~
heliumcraft
There are different solutions for that in the works, from sharding to plasma,
etc.. and those have their own challenges & tradeoffs (namely in terms of
security, etc..)

However engineering decisions 'on genesis' was over 3-4 years ago and at that
time doing a blockchain with smart contracts was already challenge on itself.
It's not really fair to take the knowledge and lessons from the present day
and claim those in the past without that knowledge made horrible decisions.
It's a bit like blaming google for not starting angular 1 with the
functionality of angular 4, or saying that John Resig should have created
Babel and ES7 features instead of creating jQuery.

~~~
elmar
> However engineering decisions 'on genesis' was over 3-4 years ago and at
> that time doing a blockchain with smart contracts was already challenge on
> itself. It's not really fair

Sorry when I heard about Ethereum plans 4 years ago, I tough it as a terribly
bad idea then (I didn't invest because of this, I should have invested stupid
me) in 2013 the increase size of blockchain was already an ongoing problem, I
simply tought if a decentelized ledger is already problematic to store, let's
put a lot of more information on it, it's madness..

------
zebraflask
After CryptoKitties, it's difficult to take Ethereum seriously.

~~~
bufferoverflow
That's like saying "after the fart app, it's hard to take iOS seriously".

~~~
zebraflask
I don't really take iOS all that seriously, either.

Of all the things anyone would trade for money Cryptokitties is really riding
the line between smart and so dumb it devalues the concept of Ethereum, which
might have been the point.

~~~
davesque
So...because we got hamsterdance.com at one point I guess that means the
internet is hard to take seriously?

~~~
zebraflask
Hamsterdance.com was a masterpiece of early Internet adoption. Try to get
anything that viral.

Ethereum is a weak attempt at money laundering.

------
goldenkey
I was downvoted when I mentioned this issue 52 days ago:

[https://news.ycombinator.com/item?id=16114295](https://news.ycombinator.com/item?id=16114295)

