Disclosure of memory DoS due to headers spam
Before Bitcoin Core v24.0.1, attackers could spam nodes with low-difficulty headers chains, which
could be used to remotely crash peers.
This issue is considered High severity.
Details
Bitcoin Core stores the blockchain headers in memory. This makes it susceptible to being DoSed, by
having it download and store extremely long chains of headers, even if they are of low difficulty.
It is important to note that once crafted, an attack chain could be reused to crash any node on the
network.
The possibility of using this to attack nodes has long been known, and was the primary reason why
the checkpoint system was still in place: making an attacker start an attack at the last checkpoint
makes it far more costly than starting at the genesis block. However, over time, with decreasing
hashrate costs, even this mitigation became less effective.
This attack was independently discovered and reported to the Bitcoin Core project in January 2019 by
David Jaenson, who suggested introducing newer checkpoints as a practical mitigation. However:
* This still leaves nodes performing IBD with no protection before they receive checkpoint blocks.
* It relies on the ecosystem semi-regularly adopting updated software with new checkpoints, a
practice which Bitcoin Core contributors have long been uncomfortable with.
It later got increased attention when Braydon Fuller posted his “Chain width expansion”
writeup to the
bitcoin-dev mailing list in October 2019. He had previously responsibly reported it to the Bitcoin
Core security list. The suggested approach was not adopted in Bitcoin Core due to concerns about
network convergence when limiting the number of parallel chains.
At the time, the computational cost of creating a huge low-difficulty headers chain was equal to
about 32.28% of mining one block at the tip. That is a cost of about 4.12 BTC since the block reward
then was about 12.77 BTC.
By February 2022, the cost of the attack had dropped further to around 14.73% of the cost of mining
a block, and this prompted investigation of alternative solutions. If unaddressed, the cost today
(September 2024) would just be 4.44% of a block. These figures translate to a cost of about 1.07 BTC
and 0.14 BTC respectively, given the block reward at these dates.
A protection against this DoS was implemented in Bitcoin Core PR
#25717, whereby the node will first verify a
presented chain has enough work before committing to store it. With that, Bitcoin Core no longer
relies on having checkpoints to protect against any known attacks.
Attribution
Credit goes to David Jaenson and Braydon Fuller for independently re-discovering the attack,
estimating its cost and suggesting modifications.
Credit goes to Suhas Daftuar and Pieter Wuille for researching a satisfying fix and implementing it.
Timeline
* 2010-07-17 - Bitcoin 0.3.2 is released, which introduces checkpoints. They protect among other
things against low-difficulty block spam.
* 2011-11-21 - Bitcoin 0.5.0 is released, which skips script validation for blocks before the last
checkpoint. This makes the role of checkpoints even more security-critical.
* 2014-04-09 - Block 295000 is mined, which becomes the last Bitcoin Core checkpoint. The protection
offered by checkpoints against block spam starts eroding from this point on as hashrate costs
decrease.
* 2015-02-16 - Bitcoin Core 0.10.0 is released, with headers-first synchronization. This weakens the
low-difficulty block spam attack to a block header spam attack.
* 2017-03-08 - Bitcoin Core 0.14.0 is released, which disentangles the skipping of script validation
from checkpoints, leaving them only relevant for protecting against block header spam.
* 2019-01-28 - David Jaenson reports this issue to the Bitcoin Core security mailing list.
* 2019-09-18 - Braydon Fuller emails the Bitcoin Core security list with a paper titled “Bitcoin
Chain Width Expansion Denial-of-Service
Attacks”, which discusses the dangers of
block and block header spam, a cost analysis,… http://dlvr.it/TDPpd8
0 notes
Disclosure of remote crash due to addr message spam
Disclosure of the details of an integer overflow bug which causes an assertion
crash, a fix for which was released on September 14th, 2021 in Bitcoin Core
version v22.0.
This issue is considered High severity.
Details
CAddrMan has a 32-bit nIdCount field that is incremented on every insertion
into addrman, and which then becomes the identifier for the new entry. By
getting the victim to insert 232 entries (through e.g. spamming addr
messages), this identifier overflows, which leads to an assertion crash.
Attribution
Credit goes to Eugene Siegel for discovering and disclosing the vulnerability,
and to Pieter Wuille for fixing the issue in
https://github.com/bitcoin/bitcoin/pull/22387.
Timeline
* 21-06-2021 - Initial report sent to
[email protected] by Eugene Siegel
* 19-07-2021 - Fix is merged (https://github.com/bitcoin/bitcoin/pull/22387)
* 13-09-2021 - v22.0 is released
* 31-07-2024 - Public disclosure http://dlvr.it/TBK8d2
0 notes
Disclosure of the impact of an infinite loop bug in the miniupnp dependency
Disclosure of the impact of an infinite loop bug in the miniupnp dependency on
Bitcoin Core, a fix for which was released on September 14th, 2021 in Bitcoin
Core version v22.0.
This issue is considered Low severity.
Details
Miniupnp, the UPnP library used by Bitcoin Core, would be waiting upon
discovery for as long as it receives random data from a device on the network.
In addition it would allocate memory for every new device information. An
attacker on the local network could pretend to be a UPnP device and keep
sending bloated M-SEARCH replies to the Bitcoin Core node until it runs out of
memory.
Only users running with the -miniupnp option would have been
affected by this bug as Miniupnp is otherwise turned off by default.
Attribution
Credit goes to Ronald Huveneers for reporting the infinite loop bug to the
miniupnp project, and to Michael Ford (Fanquake) for the report to the Bitcoin
Core project along with a PoC exploit to trigger an OOM and a pull request to
bump the dependency (containing the fix).
Timeline
* 17-09-2020 - Initial report of infinite loop bug to miniupnp by Ronald Huveneers
* 13-10-2020 - Initial report sent to
[email protected] by Michael Ford
* 23-03-2021 - Fix is merged (https://github.com/bitcoin/bitcoin/pull/20421)
* 13-09-2021 - v22.0 is released
* 31-07-2024 - Public disclosure http://dlvr.it/TBK8cr
0 notes
Bitcoin Core 26.2 released
Bitcoin Core version 26.2 is now available for download. See the release notes for more information about the many
bug fixes in this release.
If you have any questions, please stop by the #bitcoin IRC chatroom
(IRC, web) and we’ll do our best to help you. http://dlvr.it/T9R3kl
0 notes
Disclosure of CPU DoS due to malicious P2P message (≤ version 0.19.2)
A malformed GETDATA message could trigger an infinite loop on the receiving node, using 100% of
the CPU allocated to this thread and not making further progress on this connection.
This issue is considered Low severity.
Details
Before Bitcoin Core 0.20.0, an attacker (or buggy client, even) could send us a GETDATA message
that would cause our net_processing thread to start spinning at 100%, and not make progress
processing messages for the attacker peer anymore. It would still make progress processing messages
from other peers, so it is just a CPU DoS with low impact beyond that (not making progress for
attacker peers is a non-issue). It also increases per-peer long-term memory usage up by 1.5 MB per
attacker peer.
John Newbery opened PR #18808 to fix this issue by
only disclosing the lack of progress.
Attribution
Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.
Timeline
* 2020-04-29 John Newbery opens #18808
* 2020-05-08 John Newbery reports his finding by email
* 2020-05-12 #18808 is merged
* 2020-06-03 Bitcoin Core version 0.20.0 is released with a fix
* 2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
* 2024-07-03 Public disclosure. http://dlvr.it/T96bk8
0 notes
Disclosure of crash due to malicious BIP72 URI (≤ version 0.19.2)
Bitcoin-Qt could crash upon opening a BIP72 URI.
This issue is considered Medium severity.
Details
BIP72 extends the BIP21 URI scheme
with an r parameter to fetch a payment request from. An attacker could simply point the URL
contained in the r parameter to a very large file, for which Bitcoin-Qt would try to allocate
enough memory and crash.
The victim could get tricked into opening a rogue payment request. The large download would happen
in the background with little to no output in the GUI until the application runs out of memory.
Attribution
Credits go to Michael Ford (Fanquake) for responsibly disclosing the issue and providing a PoC.
Timeline
* 2019-08-12 Michael Ford reports the bug to Cory Fields and Wladimir Van Der Laan
* 2019-10-16 Michael Ford opens PR #17165 to get rid of BIP70 support entirely
* 2019-10-26 Michael’s PR is merged into Bitcoin Core
* 2020-06-03 Bitcoin Core version 0.20.0 is released
* 2021-09-13 The last vulnerable Bitcoin Core version (0.19.0) goes EOL
* 2024-07-03 Public disclosure http://dlvr.it/T96bkL
0 notes
Disclosure of memory DoS due to malicious P2P message (≤ version 0.19.2)
A node could be forced to allocate a significant amount of memory upon receiving a specially crafted
INV message. This was particularly an issue for nodes with little available memory or a large
number of connections.
This issue is considered Medium severity.
Details
An INV message filled with 50,000 block items could cause 50,000 getheaders responses to be sent
in a single ProcessMessages() call. Each response contains a locator and is around 1 kB. All would
be put into the send buffer at once. The attacker could just refuse to receive data to prevent the
50 MB buffer from draining.
John Newbery opened PR #18962 to fix this issue
pretexting a bandwidth gain from sending a single GETHEADERS per received INV.
Attribution
Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.
Timeline
* 2020-05-08 John Newbery reports his finding by email
* 2020-05-12 John Newbery opens #18962
* 2020-05-14 #18962 is merged
* 2020-06-03 Bitcoin Core version 0.20.0 is released with a fix
* 2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
* 2024-07-03 Public disclosure. http://dlvr.it/T96bjv
0 notes
Disclosure of memory DoS using low-difficulty headers (≤ version 0.14.3)
After Bitcoin Core 0.12.0 and before Bitcoin Core 0.15.0 a node could be spammed with minimum
difficulty headers, which could possibly be leveraged to crash it by OOM.
This issue is considered Medium severity.
Details
Before the introduction of headers
pre-synchronisation, nodes relied exclusively on
checkpoints to avoid getting spammed by low-difficulty headers.
In Bitcoin Core 0.12.0 a check for headers forking before the last checkpoint’s height was moved to
after storing the header in mapBlockIndex. This allowed an attacker to grow the map unboundedly by
spamming headers whose parent is the genesis block (which only need difficulty 1 to create), as such
blocks bypassed the checkpoint logic.
Attribution
Credits to Cory Fields for finding and responsibly disclosing the bug.
Timeline
* 2017-08-08 Cory Fields privately reports the bug
* 2017-08-11 Pieter Wuille opens PR #11028 to fix it
* 2017-08-14 PR #11028 is merged
* 2017-09-14 Bitcoin Core version 0.15.0 is released with a fix
* 2018-10-03 The last vulnerable version of Bitcoin Core (0.14.3) goes end of life
* 2024-07-03 Public disclosure. http://dlvr.it/T96bk1
0 notes
Disclosure of CPU/memory DoS due to many malicious peers (≤ version 0.20.0)
Bitcoin Core maintained an unlimited list of banned IP addresses and performed a quadratic operation
on it. This could lead to an OOM crash and a CPU Dos.
This issue is considered High severity.
Details
Bitcoin Core maintained a list of banned IP addresses. This list was not bounded and could be
manipulated by an adversary. Adding new entries to this list was particularly cheap for an attacker
when considering IPV6. In addition, when receiving a GETADDR message, Bitcoin Core would scan the
entire ban list for every single address to be returned (up to 2500).
Attribution
Calin Culianu first responsibly disclosed it. Calin later publicly disclosed the bug in a PR
comment.
On the same day Jason Cox from Bitcoin ABC emailed the Bitcoin Core project to share this same
report they also received.
Timeline
* 2020-06-08 Calin Culianu privately reports the bug to the Bitcoin Core project
* 2020-06-08 Jason Cox privately shares the (same) report sent to Bitcoin ABC with Bitcoin Core
* 2020-06-08 Calin Culianu publicly discloses the vulnerability on the original PR which introduced the quadratic behaviour
* 2020-06-09 Pieter Wuille opens PR #19219 which fixes both the unbounded memory usage and the quadratic behaviour
* 2020-06-16 Luke Dashjr gets assigned CVE-2020-14198 for this vulnerability after his request
* 2020-07-07 Pieter’s PR is merged
* 2020-08-01 Bitcoin Core 0.20.1 is released with the fix
* 2021-01-14 Bitcoin Core 0.21.0 is released with the fix
* 2022-04-25 The last vulnerable Bitcoin Core version (0.20.0) goes EOL
* 2024-07-03 (Official) Public Disclosure http://dlvr.it/T96bj1
0 notes
Disclosure of netsplit due to malicious P2P messages by first 200 peers (≤ version 0.20.1)
Disclosure of the details of an integer overflow bug which risked causing a network split, a fix for
which was released on January 15th, 2021 in Bitcoin Core version 0.21.0.
This issue is considered Medium severity.
Technical details
A network split vulnerability resulted from two separate bugs in the processing code of version
messages:
* Signed-integer overflow when calculating the time offset for newly connecting peers.
* abs64 logic bug (abs64(std::numeric_limits::min()) ==
std::numeric_limits::min()), resulting in a bypass of the maximum time adjustment limit.
The two bugs allow an attacker to force a victims adjusted time (system time + network time
offset) to be skewed such that any new blocks are rejected for having a timestamp that is dated too
far in the future. It should be noted that this attack assumes the attacker is among the first 200
peers to connect to the victim, as only the time offsets from those initial connections are factored
into adjusted time.
Attribution
Credit goes to practicalswift for discovering and providing the
initial fix for the vulnerability, and Pieter Wuille for the fix as well as general cleanup to the
at-risk code.
Timeline
* 2020-10-10 Initial report send to
[email protected]
* 2020-10-13 Fix merged into Bitcoin Core (https://github.com/bitcoin/bitcoin/pull/20141)
* 2021-01-15 v0.21.0 released
* 2022-04-25 The last vulnerable Bitcoin Core version (0.20.x) goes EOL
* 2024-07-03 Public disclosure http://dlvr.it/T96bjM
0 notes
Disclosure of CPU DoS / stalling due to malicious P2P message (≤ version 0.17.2)
A node could be stalled for hours when processing the orphans of a specially crafted unconfirmed
transaction.
This issue is considered High severity.
Details
After accepting a transaction into its mempool, the node would go through its cache of orphan
transactions to find if this new accepted transaction makes it possible to accept any. This search
was quadratic: for each output in the newly accepted transaction it would go through all cached
orphan transactions (limited to 100). By specially crafting the orphan transactions to be invalid
yet expensive to validate a node could be stalled for several hours.
The stall was fixed by Pieter Wuille in PR #15644
by interrupting the orphan resolution to process new messages when a match is found (whether the
orphan turns out to be valid or not).
Attribution
Credits to sec.eine for responsibly disclosing the bug and providing feedback on the fix.
Timeline
* 2019-03-19 sec.eine reports the issue to Greg Maxwell by email
* 2019-03-21 Greg Maxwell responds with information about the proposed patch
* 2019-03-22 sec.eine gives feedback on the patch (“seems solid and [..] doesn’t attract attention”)
* 2019-03-22 Pieter Wuille opens PR #15644
* 2019-04-01 PR #15644 is merged
* 2019-05-18 Bitcoin Core version 0.18.0 is released with a fix
* 2020-07-22 The issue is partially disclosed during a PR review club
* 2020-08-01 The last vulnerable Bitcoin Core version (0.17.x) goes EOL
* 2024-07-03 Public disclosure. http://dlvr.it/T96bjg
0 notes
Disclosure of censoring unconfirmed transactions to a specific victim (≤ version 0.20.2)
An attacker could prevent a node from seeing a specific unconfirmed transaction.
This issue is considered Medium severity.
Details
Before this issue was fixed in PR 19988, the “g_already_asked_for” mechanism was used to schedule GETDATA requests for transactions. The SendMessages() function would send out GETDATAs for transactions recently announced by peers, remembering when that request was sent out in g_already_asked_for. However, this g_already_asked_for was a “limitedmap” data structure, with a bounded size that would forget the oldest entries if it reaches 50000 entries. This makes the following attack possible:
* The attacker is the first to announce a legitimate transaction T to the victim.
* The victim requests T from the attacker using GETDATA.
* The attacker does not respond to GETDATA until close to the time when the victim would request T from other peers (~60 seconds).
* Then, the attacker carefully spams the victim with bogus announcements, causing the victim’s g_already_asked_for to evict T.
* The attacker announces T again to the victim (due to how the queueing works in m_tx_process_time, this does not need to be timed particularly accurately).
* The victim, not finding T in g_already_asked_for will treat it as a new announcement, sending a new GETDATA for it to the attacker.
* The attacker again does not respond to GETDATA.
* etc.
This way, the attacker can prevent the victim from ever requesting the transaction from anyone but the attacker.
Attribution
Responsibly disclosed by John Newbery, claiming discovery by Amiti Uttarwar and him.
Timeline
* 2020-04-03 John Newbery reports the bug in an email to Suhas Daftuar and others
* 2020-05-08 John Newbery suggests an approach to fixing the bug
* 2020-09-21 Pieter Wuille opens PR #19988 as a comprehensive approach to fixing this and other bugs
* 2020-10-14 Pieter’s PR is merged
* 2021-01-14 Bitcoin Core version 0.21.0 is released with a fix
* 2022-04-25 The last vulnerable Bitcoin Core version (0.20.0) goes EOL
* 2024-07-03 Public disclosure http://dlvr.it/T96bhn
0 notes
Disclosure of memory DoS due to malicious P2P message from many peers (≤ version 0.10.0)
A node could be forced to allocate large buffers when receiving a message, which could be leveraged to remotely crash it by OOM.
This issue is considered Medium severity.
Details
Without a tighter bound, received messages’ size was limited by the maximum serialized message size
of 32 MiB. An attacker could force a node to allocate this much RAM per connection, which may lead
to an OOM.
PR #5843 reduced the size P2P messages can have
before receiving the payload. This reduces the per-peer receive buffer memory size a malicious peer
can cause. The PR reduced the number from 32 MiB to 2 MiB, which was later increased back to 4 MB as
part of the Segwit BIP144 changes.
Attribution
Reported to Greg Maxwell by bitcointalk user Evil-Knievel. Fixed by Pieter Wuille.
Timeline
* 2015-02-05 Evil-Knievel reports the vulnerability to Greg Maxwell through bitcointalk private messages.
* 2015-??-?? CVE-2015-3641 is registered for it.
* 2015-03-01 PR #5843 is opened to fix it.
* 2015-03-06 PR #5843 is merged.
* 2015-03-09 The fix is backported to version 0.10.1.
* 2015-04-27 Bitcoin Core version 0.10.1 is released with a fix.
* 2015-06-25 A disclosure is pre-announced.
* 2015-07-07 Disclosure is postponed.
* 2016-08-23 The last vulnerable Bitcoin Core Version (0.10.x) goes EOL
* 2024-07-03 Public disclosure. http://dlvr.it/T96bhP
0 notes
Disclosure of potential remote code execution due to bug in miniupnpc (≤ version 0.11.1)
A buffer overflow enabling a significant data leak was discovered in miniupnpc. Combined with the then
recently-disclosed CVE-2015-6031 it enabled an RCE in miniupnpc which could have led to an RCE
in Bitcoin Core. This was fixed in Bitcoin Core 0.12,
released in February 2016.
This issue is considered Medium severity.
Details
CVE-2015-6031, disclosed in September 2015, made
it possible for a malicious UPnP server to remotely crash a Bitcoin Core process on the local
network at startup. See here for details. The fix
was pulled in Bitcoin Core and released in version
0.11.1, released in October 2015. UPnP was then
turned off by default.
CVE-2015-6031 disclosed a buffer overflow, which in addition to enabling a remote crash could have
made it possible to remotely execute code on a victim’s machine. While investigating this
possibility, Wladimir J. Van Der Laan found another buffer overflow in miniupnpc which enabled a
significant data leak. This was fixed by Wladimir in
miniupnpc in commit
4c90b87ce3d2517097880279e8c3daa7731100e6. The fix was then pulled into Bitcoin
Core and released as part of version 0.12.
This data leak did not disclose secret information (such as the wallet’s private keys) directly. But
combined with another stack overflow (such as the one disclosed in CVE-2015-6031) this made it
possible to trigger a remote code execution. Wladimir demonstrated this against Ubuntu’s miniupnpc
version 1.6-precise. The specific approach used in this exploit was however not directly portable
to Bitcoin Core.
Attribution
Credits go to Aleksandar Nikolic for identifying CVE-2015-0035 and to Wladimir J. Van Der Laan for
investigating its impact and discovering the second buffer overflow.
Timeline
* 2015-09-15 CVE-2015-0035 is
fixed and
disclosed.
* 2015-10-09 PR #6789 is merged in Bitcoin Core
* 2015-10-14 Wladimir’s remote code execution by leveraging the second buffer overflow is disclosed
to Ubuntu security and Bitcoin developers.
* 2015-10-15 Bitcoin Core 0.11.1 is
released
* 2015-10-26 The fix for the second buffer overflow is
merged into miniupnpc.
* 2015-12-18 The fix is pulled into Bitcoin Core.
* 2016-02-23 Bitcoin Core version 0.12 is
released.
* 2017-03-08 The last vulnerable Bitcoin Core Version (0.11.x) goes EOL
* 2024-07-03 Public disclosure http://dlvr.it/T96bf2
0 notes
Bitcoin Core 27.1 released
Bitcoin Core version 27.1 is now available for download. See the release notes for more information about the
bug fixes in this release.
If you have any questions, please stop by the #bitcoin IRC chatroom
(IRC, web) and we’ll do our best to help you. http://dlvr.it/T8Pc4D
0 notes
Bitcoin Core 27.0 released
Bitcoin Core version 27.0 is now available for download. See the release notes for more information about the
bug fixes in this release.
If you have any questions, please stop by the #bitcoin IRC chatroom
(IRC, web) and we’ll do our best to help you. http://dlvr.it/T5dmXF
0 notes
Bitcoin Core 25.2 released
Bitcoin Core version 25.2 is now available for download. See the release notes for more information about the
bug fixes in this release.
If you have any questions, please stop by the #bitcoin IRC chatroom
(IRC, web) and we’ll do our best to help you. http://dlvr.it/T5cY7C
0 notes