CVE-2018-1000891 – Uncontrolled resource consumption when receiving messages with invalid checksums<\/span><\/h2>\n\n\n\nImpact of vulnerability: Denial of Service<\/span>Severity: Medium<\/span>Difficulty: Low<\/span>Recommendation: upgrade to Bitcoin SV 0.1.1<\/span><\/p>\n\n\n\nIt\u2019s currently possible for a malicious remote host to send an arbitrary number of p2p messages with invalid checksums, wasting the victim node\u2019s 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.<\/span><\/p>\n\n\n\nExploit Scenario<\/b><\/h5>\n\n\n\n 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 \u200b GetMessageHash\u200b ) of the victim node.<\/span><\/p>\n\n\n\nThe 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\u200b, 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.<\/span><\/p>\n\n\n\nThe 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.<\/span><\/p>\n\n\n\nCVE-2018-1000892 – Uncontrolled resource consumption when receiving sendheaders messages<\/span><\/h2>\n\n\n\nImpact of vulnerability: Denial of Service<\/span>Severity: Medium<\/span>Difficulty: Low<\/span>Recommendation: upgrade to Bitcoin SV 0.1.1<\/span><\/p>\n\n\n\nA 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 \u200b sendheaders\u200b messages, which require only 24 bytes and have, by definition, a zero-length body. Receiving 2739 null-sized \u200b 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.<\/span><\/p>\n\n\n\nExploit Scenario<\/b><\/h5>\n\n\n\n A malicious node intentionally floods a victim node with empty \u200b sendheader\u200b 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\u200b messages.<\/span><\/p>\n\n\n\nThe 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\u200b, 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.<\/span><\/p>\n\n\n\nThe 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.<\/span><\/p>\n\n\n\nCVE-2018-1000893 – Uncontrolled resource consumption when deserializing transactions<\/span><\/h2>\n\n\n\nImpact of vulnerability: Denial of Service<\/span>Severity: Medium<\/span>Difficulty: Low<\/span>Recommendation: upgrade to Bitcoin SV 0.1.1<\/span><\/p>\n\n\n\nA specially crafted message with a falsified value in its size field causes Bitcoin SV to allocate and create a massive amount of CTxOut\u200b objects when the message is deserialized.<\/span><\/p>\n\n\n\nExploit Scenario<\/b><\/h5>\n\n\n\n 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\u2019s 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.<\/span><\/p>\n\n\n\nIn 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.<\/span><\/p>\n\n\n\nThe 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.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"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 […]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[73],"tags":[],"lang":"en","translations":{"en":2587},"yoast_head":"\n
Denial of Service Vulnerabilities Repaired in Bitcoin SV version 0.1.1 - Bitcoin SV<\/title>\n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n \n \n \n