Skip to content

Commit 2d4af7c

Browse files
darosiorsipa
andcommitted
posts: disclose historical tx relay censorship vulnerability (g_already_asked_for rolling)
Co-Authored-By: Pieter Wuille <[email protected]>
1 parent 4b564d3 commit 2d4af7c

File tree

1 file changed

+51
-0
lines changed

1 file changed

+51
-0
lines changed
Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
---
2+
title: Disclosure of censoring unconfirmed transactions to a specific victim (&le; version 0.20.2)
3+
name: blog-disclose-already-asked-for
4+
id: en-blog-disclose-already-asked-for
5+
lang: en
6+
type: advisory
7+
layout: post
8+
9+
## If this is a new post, reset this counter to 1.
10+
version: 1
11+
12+
## Only true if release announcement or security annoucement. English posts only
13+
announcement: 1
14+
15+
excerpt: >
16+
Public disclosure of a transaction relay censorship vulnerability affecting old versions of Bitcoin Core.
17+
---
18+
19+
An attacker could prevent a node from seeing a specific unconfirmed transaction.
20+
21+
This issue is considered **Medium** severity.
22+
23+
## Details
24+
25+
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 `GETDATA`s 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:
26+
* The attacker is the first to announce a legitimate transaction T to the victim.
27+
* The victim requests T from the attacker using `GETDATA`.
28+
* The attacker does not respond to `GETDATA` until close to the time when the victim would request T from other peers (~60 seconds).
29+
* Then, the attacker carefully spams the victim with bogus announcements, causing the victim's `g_already_asked_for` to evict T.
30+
* 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).
31+
* 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.
32+
* The attacker again does not respond to `GETDATA`.
33+
* etc.
34+
35+
This way, the attacker can prevent the victim from ever requesting the transaction from anyone but the attacker.
36+
37+
## Attribution
38+
39+
Responsibly disclosed by John Newbery, claiming discovery by Amiti Uttarwar and him.
40+
41+
## Timeline
42+
43+
- 2020-04-03 John Newbery reports the bug in an email to Suhas Daftuar and others
44+
- 2020-05-08 John Newbery suggests an approach to fixing the bug
45+
- 2020-09-21 Pieter Wuille opens [PR #19988](https://github.com/bitcoin/bitcoin/pull/19988) as a comprehensive approach to fixing this and other bugs
46+
- 2020-10-14 Pieter's PR is merged
47+
- 2021-01-14 Bitcoin Core version 0.21.0 is released with a fix
48+
- 2022-04-25 The last vulnerable Bitcoin Core version (0.20.0) goes EOL
49+
- 2024-07-03 Public disclosure
50+
51+
{% include references.md %}

0 commit comments

Comments
 (0)