Denial of Service Vulnerabilities Repaired in Bitcoin SV version 0.1.1
by Jimmy Nguyen
March 1, 2019 (5min read)
As part of its commitment to professionalise the Bitcoin development process, the Bitcoin SV Node implementation team engaged the services of Trail of Bits, a leading cybersecurity research company...

As part of its commitment to professionalise the Bitcoin development process, the Bitcoin SV Node implementation team engaged the services of Trail of Bits, a leading cybersecurity research company with expertise in blockchain technologies, to perform a security audit of the Bitcoin SV Node implementation source code. Three of the vulnerabilities that were discovered by this security audit could be exploited to perform denial of service attacks on Bitcoin.

These vulnerabilities were responsibly disclosed to the software development teams of Bitcoin Unlimited, Bitcoin XT, Bitcoin ABC, and Bitcoin Core. An analysis of the vulnerable portions of the source code indicated that these software implementations may be affected by these vulnerabilities because the source code for these implementations are derived from the same origin.

These vulnerabilities have been addressed in release 0.1.1 of Bitcoin SV. The Bitcoin SV Node implementation team strongly encourages all users of the Bitcoin SV Node implementation to upgrade their software as quickly as possible.

CVE-2018-1000891 – Uncontrolled resource consumption when receiving messages with invalid checksums

Impact of vulnerability: Denial of Service
Severity: Medium
Difficulty: Low
Recommendation: upgrade to Bitcoin SV 0.1.1

It’s currently possible for a malicious remote host to send an arbitrary number of p2p messages with invalid checksums, wasting the victim node’s CPU and network resources. This activity is not classified as a misbehaving node, and will never result in an IP ban. The remote host can send these messages unsolicited, without waiting for a protocol session to be initiated by the victim via its peer discovery process.

Exploit Scenario

A malicious node intentionally generates and sends messages with invalid checksums, and consumes both network resources (available TCP ports, network bandwidth) and CPU time (to compute the SHA256 hash of the message payload, in ​ GetMessageHash​ ) of the victim node.

The impact of such a resource consumption attack appears to be limited only by the throughput of the network connection between the attacker and the victim. The Bitcoin SV software itself implements various DoS mitigations​, but those do not include any rate-limiting on traffic from a peer. In the worst-case scenario of resource consumption, the attacker would be able to prevent the victim from mining.

The vector for exploiting this vulnerability is any p2p connection to or from the node. Bitcoin nodes usually make outbound p2p network connections to other nodes and also accept inbound p2p connections from any source. Either type of connection, inbound or outbound, could be a vector for an exploit of this vulnerability.

CVE-2018-1000892 – Uncontrolled resource consumption when receiving sendheaders messages

Impact of vulnerability: Denial of Service
Severity: Medium
Difficulty: Low
Recommendation: upgrade to Bitcoin SV 0.1.1

A Bitcoin SV node will accept up to 64KB of messages at a time from another node. This is enough space to deliver a sequence of 2739 ​ sendheaders​ messages, which require only 24 bytes and have, by definition, a zero-length body. Receiving 2739 null-sized ​ sendheaders messages keeps the victim node busy for a while, since nodes are expected to announce new blocks by sending the header of the new block along with any other blocks that it believes a peer might need.

Exploit Scenario

A malicious node intentionally floods a victim node with empty ​ sendheader​ messages, and consumes both network resources (available TCP ports, network bandwidth) and CPU time (message processing) of the victim node. The attack can be sent repeatedly because there is currently no logic to detect this behavior or ban a node for sending too many sendheaders​ messages.

The impact of such a resource consumption attack appears to be limited only by the throughput of the network connection between the attacker and the victim. The Bitcoin SV software itself implements various DoS mitigations​, but those do not include any rate-limiting on traffic from a peer. In the worst-case scenario of resource consumption, the attacker would be able to prevent the victim from mining.

The vector for exploiting this vulnerability is any p2p connection to or from the node. Bitcoin nodes usually make outbound p2p network connections to other nodes and also accept inbound p2p connections from any source. Either type of connection, inbound or outbound, could be a vector for an exploit of this vulnerability.

CVE-2018-1000893 – Uncontrolled resource consumption when deserializing transactions

Impact of vulnerability: Denial of Service
Severity: Medium
Difficulty: Low
Recommendation: upgrade to Bitcoin SV 0.1.1

A specially crafted message with a falsified value in its size field causes Bitcoin SV to allocate and create a massive amount of CTxOut​ objects when the message is deserialized.

Exploit Scenario

A malicious peer sends a message that has a valid header, but when deserialized, reports a size field of 33,554,432 (the maximum number). This wastes a significant (and asymmetric) amount of the victim node’s memory and CPU time. This condition causes an exception to be thrown, but does not cause the sender to be classified as a misbehaving peer. The attacking node will not be banned, and can repeat the attack with additional malicious messages.

In the worst-case scenario, the attacked would be able to prevent the victim from performing any useful work, including the distribution of transactions or blocks, or even mining.

The vector for exploiting this vulnerability is any p2p connection to or from the node. Bitcoin nodes usually make outbound p2p network connections to other nodes and also accept inbound p2p connections from any source. Either type of connection, inbound or outbound, could be a vector for an exploit of this vulnerability.

Articles