Skip to main content

The Good, the Bad and the Ugly Details of One of Bitcoin’s Nastiest Bugs Yet

The good news is that the Bitcoin protocol is safe and the bug was never exploited in any way. Still, it could have allowed for one of the worst attacks on Bitcoin in years.
Technical - The Good

For well over a year, versions of Bitcoin Core — Bitcoin’s leading software implementation — contained a severe software bug. The bug was fixed with Bitcoin Core 0.16.3 (and 0.17.0rc4), released this week, and the status of the Bitcoin network now appears to be safe, with no harm done. The Bitcoin Core project has since released a full disclosure report, revealing that the bug was even worse than previously thought.

These are the good, the bad and the ugly details about one of Bitcoin Core’s nastiest bugs to date. (But not in that order.)

The Bad

The bad, of course, is the bug itself, now documented as CVE-2018-17144 in the Common Vulnerabilities and Exposures databank.

The bug was introduced as part of a block relay-related performance improvement deployed in Bitcoin Core 0.14.0, officially released in March of 2017. In short, the bug would have nodes fail to reject a block containing a transaction that spends the same coins (“inputs”) multiple times. Indeed, it would allow for an (irregular) form of double-spending: arguably the very thing Bitcoin was designed to prevent.

It posed a serious problem, which could have manifested in several ways.

First, Bitcoin Core versions 0.14.0 through 0.14.2 (and, in some cases, newer versions), would have accepted the block but, at the same time, recognized that something was wrong. However, they wouldn’t be able to tell what was wrong, exactly. As a result, the node would stop operating altogether and shut down. If an invalid block caused by this bug had made its way to such nodes, they would have, in effect, crashed. That’s bad.

But it gets much worse.

Bitcoin Core versions 0.15.0 through 0.16.2 included another performance improvement, making it such that, in some cases, these nodes would no longer have realized something was wrong. Specifically, if the double-spent coin had not been moved in the same block already (which is often the case), these nodes would have accepted the transaction and block as normal. In a hypothetical, worst-case scenario, a malicious miner could have inflated Bitcoin’s money supply by copying his own coins, and anyone relying on Bitcoin Core versions 0.15.0 through 0.16.2 would have accepted these coins as valid.

Technically, the bug could also have caused a blockchain fork between affected nodes (Bitcoin Core 0.15.0 through 0.16.2 and codebase forks of it) and unaffected nodes (most notably Bitcoin Core 0.13.2 and older, as well as some alternative Bitcoin implementations). This is unlikely, however, since the latter category probably doesn’t have sufficient hash power behind it to generate even a single block within a couple of days — let alone several blocks. These nodes would have instead stalled, waiting for a valid block.

Still, the bug in question could have allowed for one of the worst attacks on Bitcoin in years. It’s sobering for many that this bug made it into a release of Bitcoin’s leading software implementation, as well as several codebase forks of it, and remained unnoticed for about 18 months.

The Good

Now, the good news.

The first and main piece of good news is that the bug has never been exploited in any way.

The second piece of good news is that it was not very likely the bug would ever have been exploited in the first place. This is because the attack could only have been exploited by a miner intentionally creating an “attack” block — not by a miner doing so by accident and also not by a regular user.

This means that a miner would have had to knowingly risk forfeiting a regular block reward worth some $80,000. An attack like this would have been noticed fairly quickly — everything happens on a public blockchain, while crash reports would probably have flooded chat rooms and forums. At that point, the Bitcoin user base would certainly agree that the added inflation was, in fact, caused by a bug — and should not be accepted as a new protocol rule.

Therefore, like with the bug that caused the value overflow incident in 2010 or the bug that split the Bitcoin network in 2013, a majority of miners (by hash power) would have either upgraded or downgraded their software quickly, rejecting the “attack block” to mine on the “honest chain” instead. As soon as this honest chain overtook the “attack chain,” even vulnerable nodes would have switched to the honest chain and disregarded the attack chain, leaving the attacking miner without any block reward.

Further, coins on the attack chain would presumably have dropped in value rather quickly: Markets are unlikely to value a coin that can be copied “out of thin air” by a malicious miner. As such, this miner would have immediately undermined the value of the same coins being copied, possibly defeating the point of the attack. (Granted, the miner could also make money by shorting the markets, but this still comes with significant risks.)

The third piece of good news is that the bug was responsibly disclosed by an unknown person on Monday to several developers working on Bitcoin Core (as well as Bitcoin Cash implementations Bitcoin ABC and Bitcoin Unlimited). It was originally presented as a denial of service (DoS) bug which, as mentioned, is accurate for Bitcoin Core versions 0.14.0 through 0.14.2. But on further examination,Bitcoin Core contributor and Chaincode Labs employee Matt Corallo found that the same bug was also an inflation vulnerability.

The bug was quickly patched and released on Tuesday in a new Bitcoin Core minor release: Bitcoin Core 0.16.3. The bug is also patched in the fourth and latest release candidate for Bitcoin Core’s upcoming major release, 0.17.0. Meanwhile, the select group of Bitcoin Core contributors that were aware of the bug started reaching out to key players in the Bitcoin ecosystem, most notably miners and large businesses, asking them to upgrade to Bitcoin Core 0.16.3. Regular users were also urged to upgrade.

The fourth piece of good news is that a majority of miners on the network has probably upgraded to get rid of the bug by now. This means that even if an attacker were to try and exploit it, he wouldn’t get very far. The honest miners would overtake the attack chain sooner rather than later, at which point even non-upgraded nodes would accept the honest chain as the only valid chain. To err on the side of safety, users are currently recommended to wait for extra confirmations before accepting a payment, however.

(In technical terms, the effects on the Bitcoin protocol are as follows: Bitcoin Core 0.15.0 introduced an "accidental hard fork" that was never triggered or acted on by miners and, therefore, never led to a blockchain fork. This “hard fork” has practically been undone by an intentional, miner-enforced soft fork over the past couple of days, possibly also enforced by the Bitcoin economy at this point in time.)

The Ugly

The severity of a bug like this can be tricky to deal with on an open, decentralized, continuously operating network, supported by open-source software. As exemplified when Bitcoin Unlimited patched a bug in early 2017, the very act of fixing a vulnerability in the code might reveal it to potential adversaries, opening a window of attack until the fix is widely deployed on nodes in the field.

To avoid such attacks, those Bitcoin Core contributors aware of the problem decided not to make the severity of the bug public right away. Initially omitting some information from miners, companies and the greater public, they opted to disclose the DoS vulnerability — but not the inflation vulnerability. They hoped that the DoS vulnerability (and some strong recommendations) would be enough reason for users to upgrade, without tipping off a potential attacker. A full disclosure would follow later.

However, not everyone shared this approach. As the bug came under the spotlight, more people started to figure out on their own that the bug was more severe than just a DoS vulnerability. It’s rumoured that some started to leak the full extent of the vulnerability, arguably putting the Bitcoin network at greater risk of attack. When the vulnerability was reported on Hacker News (though later retracted), there was little reason to keep it under the covers much longer.

Fortunately, by then, it seemed to the Bitcoin Core contributors in the know that most miners had upgraded, meaning that the Bitcoin network was safe. While sooner than originally planned, the Bitcoin Core project opted to publish the full disclosure by Thursday evening.

A number of altcoins based on Bitcoin’s codebase are possibly still vulnerable to the attack, however, and the fact that the weakness is now publicly known probably does not help. While the leading implementations of the biggest Bitcoin codebase-based cryptocurrencies — most notably Bitcoin Cash’s Bitcoin ABC — deployed fixes and are also safe by now, smaller coins may still be at risk.

Update Saturday, September 22nd: Pseudonymous Bitcoin Unlimited developer "awemany" has come forward as the person who found the bug.

For more details also see the CVE-2018-17144 Full Disclosure by the Bitcoin Core project. It is still recommended that users and miners upgrade to Bitcoin Core 0.16.3 (or Bitcoin Core 0.17.0rc4).