
Crippling DDoS vulnerability put the entire Bitcoin market at risk - sahin-boydas
https://thenextweb.com/hardfork/2018/09/20/bitcoin-core-vulnerability-blockchain-ddos/
======
guidovranken
I spend a lot of time looking for bugs in cryptocurrency code. In spite of
this finding, I'd say that Bitcoin Core is among the safest cryptocurrency
applications. The average random C/C++ open source project suffers from far
more potential issues, for example [1].

Related, here's an unfixed btcd (Go Bitcoin client) DoS [2].

[1] [https://bugs.chromium.org/p/oss-
fuzz/issues/list?q=imagemagi...](https://bugs.chromium.org/p/oss-
fuzz/issues/list?q=imagemagick)

[2]
[https://github.com/btcsuite/btcd/issues/1287](https://github.com/btcsuite/btcd/issues/1287)

~~~
simias
You may be right about the relative security of Bitcoin (given that it's the
oldest and one of the most audited codebases while also missing some of the
more complex and potentially problematic features of other cryptocurrencies it
seems like a reasonable assumption) however I'm not sure if it makes a lot of
sense to compare it with other "random" open source projects.

The problem with Bitcoin is that any vulnerability can usually be exploited
very easily for huge gains. You have a DDoS? Short BTC, run it, make millions.
Remote code execution in the client? Steal funds, make millions. Easy and
untraceable if you're careful. That's the whole drawback of the immutable
ledger approach, if you get screwed the only solution is to convince everybody
else to do a hardfork. If you're a bitcoin billionaire with relations in the
big bitcoin shops you could get it to work, if you're a rando with a dozen
bitcoins stolen from your account you're on your own.

Even something as bad as heartbleed seems almost benign in comparison since
it's significantly harder to exploit, especially at a large scale.

~~~
CVE-2018-17144
Bitcoin Core has, from day one, been a remarkably safe code base generally
speaking. The protocol is free (or used to be) of any string manipulation or
other behavior that often leads to code execution. Many major issue causing
features were added after the departure of Satoshi, and are generally
considered to be mistakes for other reasons (BIP70 introduced a dependency on
OpenSSL for the GUI wallet, which is being deprecated and is now a compile
time option). For the most part any issues in the original code are to do with
consensus level understanding of how the system operated, which is to be
expected given that the entire construction was novel at the time of its
creation. People often repeat a mantra that the Satoshi code was bad, when it
was surprisingly problem free given the enormous amount it accomplishes.

I personally pondered if this particular issue would have any market effects
and concluded that it would not substantially. This is based on fact that
there's altcoins in existence with > 800 day consensus level failures
disclosed privately, or publicly known, which still have reasonably active
trading. Some altcoins manage to exist with almost no operational network at
all, just a pool, a node or two run by the creator, and an exchange with
substantial internal volume and not a lot else.

For altcoins in particular it's difficult to actually know if this is
representative of what would happen in Bitcoin, some of the issues I'm aware
of in altcoins simply haven't been exploited because there's not enough profit
in it at the moment, even though the design decisions in these altcoins (eg,
facets of proof of stake) are then used to justify the safety of other
systems.

~~~
village-idiot
Personally I believe that those altcoins trading despite serious consensus
issues is a sign that we’re in an asset bubble of some sorts.

In a healthy market, assets that do not deliver on their most basic premise
should trade down to zero eventually.

~~~
nostrademons
This is an interesting premise when applied to the stock market.

In theory, the value of a stock is the discounted value of all future cash
flows, on the premise that all profits (in excess of debt servicing etc.)
belong to the shareholders, and they have a legal claim on that cash.

In practice, have you ever known a company who, at the top of their product
cycle, says "Welp, we got no idea what we could possibly spend all this money
on that has a positive ROI in excess of what you could get elsewhere in the
market, so here's your dividend, we'll keep raking in the cash for you as long
people want to buy our products, and then we'll liquidate and return the cash
to our equity holders"? Usually the death throes of a company involve them
hiring a series of excessively overpriced turnaround CEOs, firing them with
multi-million-$ severance packages, acquiring promising startups for lots of
equity which they end up killing, and paying a large and disengaged workforce
to search for other jobs.

They do eventually trade down to zero eventually, which proves your point, but
the conclusion one could draw is that every individual stock is actually an
asset bubble. They rarely, if ever, end up returning the company's profits to
shareholders, but shareholders who exit when it looks like there will be a lot
of profits in the future can make a lot of money at the expense of the
shareholders they sell to.

~~~
village-idiot
One could make the argument that a dying company is just a very slow and
inefficient exit scam, and that the shadiest of ICOs have just made the
process much more efficient.

------
apo
From the commit that fixes the issue (CVE-2018-17144), the root cause was
failure to call checkTransaction with the third (last) argument set to true:

[https://github.com/bitcoin/bitcoin/pull/14249/files](https://github.com/bitcoin/bitcoin/pull/14249/files)

checkTransaction is defined in verify.cpp:

[https://github.com/bitcoin/bitcoin/blob/master/src/consensus...](https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_verify.cpp#L159)

The last argument, fCheckDuplicateInputs, causes inputs to be checked for
duplicates. A comment inside this method notes:

 _/ / Check for duplicate inputs - note that this check is slow so we skip it
in CheckBlock_

To summarize, the fix appears to replace the faster call to checkTransaction
in CheckBlock with the slower version that checks for duplicate inputs in each
transaction of a new block. What's not clear to me yet is how failure to check
for duplicate inputs in a block's transactions leads to DoS.

Many consider Bitcoin Core to define the Bitcoin protocol. If this is true,
then the new release can be considered a soft fork update.

Previously, blocks containing transactions with duplicate inputs would have
been considered valid. Now, such a block will be rejected by patched nodes.

This case is an excellent example of how difficult it is to determine what
exactly the Bitcoin protocol actually requires.

We only gradually "discover" the protocol by exhaustively following every
branch of the Bitcoin Core code base.

~~~
CVE-2018-17144
> Previously, blocks containing transactions with duplicate inputs would have
> been considered valid. Now, such a block will be rejected by patched nodes.

No, they would have crashed the node, they would not have been accepted as
valid. This is not a soft fork.

~~~
apo
From the Wiki:

 _A softfork is a change to the bitcoin protocol wherein only previously valid
blocks /transactions are made invalid. ..._

[https://en.bitcoin.it/wiki/Softfork](https://en.bitcoin.it/wiki/Softfork)

It's not clear to me yet under what conditions a node would crash. With a
single duplicate input? With dozens of duplicate inputs? Duplicate inputs
spending segwit outputs?

If some duplicate inputs would have been permitted without crashing nodes then
the update appears to fit the definition of soft fork.

edit: also, it appears the DoS vuln doesn't apply to pre-0.14 nodes. Either
those nodes would have rejected dup-input blocks (making 0.14 a hard fork?) or
the update just released could be seen as a soft fork.

~~~
stale2002
I've read that there was some sort of assert check, which would fail, and
cause the whole node to crash.

Therefore fixing the crash is not a "soft fork* because nothing was accepted
in the first place.

Yes, if it actually accepted the duplicate input, that would cause unlimited
inflation, which is obviously a huge deal.

Or in other words. We got extremely lucky.

~~~
earlz
There appears to be a workaround to bypass the assert check in Bitcoin Core
0.16 that allows one to mint new coins by using an input multiple times and it
be accepted by the network without crashing. Probably will be waiting until
the dust settles on this before publishing that test case though, since it's
clearly much more severe than a DoS

~~~
stale2002
O.o wow, that is way worse than I expected.

Do you have a source for where this was written up, or did you come up with
this on your own?

I just want to be able to reference back to this in the future. So whenever
you decide to publish, I'd love to check it out!

~~~
earlz
Actually it only seems to be a side effect of our test environment. Using a
more realistic environment makes it not effective, sorry for the false alarm

~~~
stale2002
Hey thanks for the update!

But I'd encourage you to do a bit more investigation.

According to Bitcoin core, there _is_ an inflation vulnerability.

[https://bitcoincore.org/en/2018/09/20/notice/](https://bitcoincore.org/en/2018/09/20/notice/)

So maybe you weren't too far off from independently discovering the
vulnerability yourself.

Edit: apparently you were credited in discovering the vulnerability yourself
in the very discloser that I linked.

Congrats!

~~~
earlz
The credit is currently wrong, it should belong to one of the developers on my
team, David Jaenson.

My comment was an early disclosure before I fully understood how sensitive the
details were. Even without going into detail or providing any code it was very
irresponsible of me to off hand just mention that possibility. It didn't click
how sensitive things were until a bitcoin core dev confirmed it. Sorry anyone
who sees this. I merely reported the exploit, David Jaenson is our genius
security researcher that definitely should deserve all credit.

~~~
CVE-2018-17144
Yeah. I'd rather you hadn't done that personally.

------
ndury
The title is kind of clickbaitish... Taken into consideration that a miner has
to sacrifice ~$80000 (12.5 BTC) I don't see this happening.

~~~
snarf21
It also isn't entirely true the entire network is/was at risk. Not all nodes
connect to all other nodes. So a malicious actor would have to waste the money
and only bring down the nodes directly connected. Most nodes today aren't
accepting new connections. Also it only affects full nodes not SPV. I think
the best attack vector would be to crash competing nodes but remember they
have to spend a block reward to do so and all they get in reward is a block
reward. The miners have enlightened self interest to not do so. I think the
risk has been blown out of proportion but they are being smart and showing an
abundance of caution to make sure this does allow for use case they aren't
considering or some other cascading failure.

~~~
CVE-2018-17144
You can walk the network and crash all nodes with listening sockets, this
ruins pretty much everything. There's some non-public infrastructure that
would perhaps make mining continue, but non-listening nodes can't exist
without sockets, and neither can SPV nodes.

------
londons_explore
Had this been exploited, it wouldn't have caused _that_ much damage.

Some exchanges would probably have gone offline for a few hours.

Nobody would have lost any money or bitcoins.

~~~
CVE-2018-17144
> Nobody would have lost any money or bitcoins.

That's not entirely true. The current crop of Lightning Network nodes rely on
their host being up for the safety of their channels. If their node is not
contactable for more than 24 hours they risk having their money stolen.

Large changes in the network graph has been shown in Bitcoin to take quite a
while to sort out, due to the way the rumoring network attempts to find stable
and reliable peers. This is still a substantial problem now, as there's only a
few thousand listening peers that can accept incoming connections out of over
10,000 total. If only those nodes were remaining online there would be
substantially reduced capacity to relay blocks and transactions for a period.

------
ccnafr
This article is wrong and plain ol' fearmongering. A coordinated denial of
service on network nodes is theoretical at best, as it would require a series
of further, orchestrated actions on the rest of the blocks to achieve it.

This flaw alone isn't likely enable such an attack. Furthermore, most nodes
will upgrade very quickly, greatly reducing the attack surface.

~~~
CVE-2018-17144
> This article is wrong and plain ol' fearmongering. A coordinated denial of
> service on network nodes is theoretical at best, as it would require a
> series of further, orchestrated actions on the rest of the blocks to achieve
> it.

This requires no action other than pushing a specific binary to an unpatched
node in order for it to crash.

The cost of producing the binary is one time, approximately $80k USD depending
on luck.

~~~
HashBasher
Wouldn't the cost be significantly higher than $80k since the miner would have
to keep his machines on for quite some time at a loss in order to mine a full
block?

------
stephengillie
> _The bug relates to its consensus code. It meant that some miners had the
> option to send transaction data twice, causing the Bitcoin network to crash
> when attempting to validate them.

As such invalid blocks need to be mined anyway, only those willing to
disregard block reward of 12.5BTC ($80,000) could actually do any real
damage._

Do the blocks need to be mined twice? Or do you just have to submit a garbage
block for the second one?

~~~
CVE-2018-17144
> Do the blocks need to be mined twice? Or do you just have to submit a
> garbage block for the second one?

No. One transaction included twice in a single block.

------
decentralised
>This could have been waaaaay worse

The cost of the attack would far exceed ~80k USD in bitcoin block rewards
because it requires a substantial amount of hashing power to have a realistic
chance of successfully producing a block that reaches consensus and is added
to the canonical chain.

~~~
CVE-2018-17144
> The cost of the attack would far exceed ~80k USD in bitcoin block rewards
> because it requires a substantial amount of hashing power to have a
> realistic chance of successfully producing a block that reaches consensus
> and is added to the canonical chain.

No, the cost is simply $80k on average to find a block, or around $5k for
BCash. If the cost to produce a block exceeded its value substantially, it
would be on a whole unprofitable for Bitcoin miners to continue existing at
this point in time (network difficulty, bitcoin price).

~~~
lawn
> BCash

It's Bitcoin Cash.

[https://medium.com/@jonaldfyookball/why-some-people-call-
bit...](https://medium.com/@jonaldfyookball/why-some-people-call-bitcoin-cash-
bcash-this-will-be-shocking-to-new-readers-956558da12fb)

------
koolba
> As such invalid blocks need to be mined anyway, only those willing to
> disregard block reward of 12.5BTC ($80,000) could actually do any real
> damage.

> While this certainly seems unlikely (barring any digital Tyler Durden-types
> wanting to destroy something beautiful), it does raise eyebrows. The great
> defence of Bitcoin is that it’s far too decentralized to be brought down by
> any single entity.

Generic turmoil of the platform could panic selling. $80K to cause mass
disruption could pay off considerably for someone shorting either bitcoin or
an altcoin.

------
runciblespoon
Are these bitcoin exchanges just a gigantic implimentation of a pyramid
scheme. I mean where is the added value coming from? Are they similar to “over
unity” machines in physics?

------
nickbauman
Isn't the proof-of-work algorithm itself a DDoS? PoW requires all nodes in the
network to see a consistent state of a transaction for it to be correct. By
definition this violates the CAP theorem.

~~~
muthdra
Small addendum to the shortcomings of the CAP conjecture:
[https://codahale.com/you-cant-sacrifice-partition-
tolerance/](https://codahale.com/you-cant-sacrifice-partition-tolerance/)

------
dev_dull
How long until a 0day wipes out the entire market?

~~~
rebuilder
What would it take to do that? Something entirely unpatchable, I expect. I'm
having trouble imagining what kind of exploit would be that powerful.

~~~
earlz
This has happened with other, much smaller, cryptocurrencies. The choice
usually agreed upon by exchanges, developers, and community is to pick a known
good block before the attack and fork the chain backwards from that point. It
requires significant downtime and is of course very complicated, but several
different cryptocurrencies have used this method and recovered to a
functioning blockchain

~~~
once_inc
> several different cryptocurrencies have used this method and recovered to a
> functioning blockchain

The most notable is Ethereum, with the DAO hack and the subsequent bailout.
Did lead to Ethereum Classic, which is a fork that gained some traction.

------
KasianFranks
We're witnessing the maturation of crypto as these kinds of resolutions only
make it stronger. It's going to be used as a flight-to-quality asset class
after the traditional markets crack in a few months.

~~~
swift532
Why do you think traditional markets should crack in a few months?

~~~
KasianFranks
1\. They always do. 2. We've been in the longest bull market in history 3.
Black Swans exists 4. The 'message of the markets' in this case, the yield
curve along with a few other related reliable predictors:
[https://fred.stlouisfed.org/series/T10Y3MM](https://fred.stlouisfed.org/series/T10Y3MM)

~~~
jrockway
Why does Bitcoin help here?

The traditional markets attempt to assign a value to the expected future value
of all (public) companies. As technology advances, goods and services can be
produced and delivered more efficiently, allowing $1 to buy more. Investing in
the stock market is using your money to drive the improvements, and selling
your stock is reaping those rewards.

Bitcoin is just a list of financial transactions that a couple of different
computers agreed on the order of.

I don't see how they are comparable.

~~~
madeuptempacct
Because people hoard stuff with a "limited amount" (i.e. gold and silver) when
they are afraid of hyper-inflation.

