← back to the blog


Bitcoin Core Vulnerability (CVE-2018–17144) Overview

Posted on October 14th, 2018 in BitcoinCore by Brandon

Bitcoin Core Vulnerability

On September 18, 2018 a Bitcoin Core update was issued (0.16.3 and 0.17.0rc4) which fixed two related critical vulnerabilities. As with most things around the Bitcoin community people are taking some extreme views of the severity of the issue. I generally try not to get caught up in binary arguments because, in my experience, the truth is usually found in the middle and rational actors will prevail.

This article attempts to provide a short overview of the vulnerability, what the effect of a nefarious actor successfully exploiting the vulnerability would have been and why the core community’s response and communication remains a core reason as to why I believe in the future of Bitcoin (or even the crypto industry at large).

Let’s start with the vulnerabilities:

  1. A Denial of Service (DoS) attack
  2. Bitcoin inflation

Denial of Service Attack

The DoS vulnerability was initially introduced in version 0.14.0 (PR 9049) which inadvertently moved consensus level checking for double spends to a system level check which did not gracefully handle the error (it halted the program entirely). This reference oversight meant that a specially crafted and mined block (created by a nefarious miner) could contain a double spend and be broadcasted to all nodes running v0.14.0.

The economics of executing the exploit were cost prohibitive (current mining reward is 12.5 BTC or ~ US$81,250) and the effects of a successful exploit would be negligible. A node that received the exploited block would freeze and the fix would simply be to restart the application. Therefore, the ROI for this exploit would be minimal. Candidates with sufficient capital and incentive to carry out this attack would probably be limited to state actors.

Bitcoin Inflation Attack

The Bitcoin inflation vulnerability was an iteration of the DoS bug but instead of crashing from the specially crafted block described above a node may accept the block as valid, essentially allowing a nefarious actor to create BTC out of thin air. The vulnerability was introduced in v0.15.0 (PR 10195) and the functionality we will focus on changed the way unspent transaction outputs (‘UTXOs’) were stored.

A minimal explanation of the specific problem would be that when a UTXOs was stored in memory (cache) the node reading the block would cras; if the UTXOs was stored to disk then this would cause Bitcoin to inflate (the Bitcoin supply would increase with the new Bitcoin being created in thin air).

The economics of this attack are potentially more attractive to nefarious actors but the distributed attack surface is small (the attacker would need to mine a specially crafted block with the double spend included and then broadcast it to all nodes running versions 0.15.0-0.16.2). Once the double spend block reached a vulnerable versioned node the newly inflated Bitcoins would be witnessed in circulation. This would more than likely cause a fork in the blockchain and a consensus would build to pick the right chain (non inflated chain). The vulnerability would also be disclosed to the Bitcoin Core Developer team and a fix would be issued with the same speed the current fix took to deploy.

Timeline of events (full timeline can be found on the full disclosure link above):

September 17, both vulnerabilities are disclosed.

September 17, both vulnerabilities are issued patches

September 18, Bitcoin Core version 0.16.3 is tagged and binaries are released

September 18-19, the Bitcoin Community is urged to upgrade their core

Final Thoughts

I think the swift response to the responsible disclosure of these vulnerabilities shows two fundamental truths about the future of this rapidly evolving economic model.

  1. Regardless of the downturn in fiat valuation, the software continues to have a robust community of first class developers who support and actively manage the ongoing future direction of this revolutionary technology.
  2. No other global monetary system is managed in such a responsible, transparent and committed manner. I have seen how closed development environments can ignore vulnerable issues like these (issues that seemingly have minimal economic incentive to exploit) because they do not have the internal resources and / or commitment to quickly resolve the issues.

© 2018 Brandon Caruana. All rights reserved