1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2102E96F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Sep 2017 05:27:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D33DB113
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Sep 2017 05:27:50 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
id 1dsMgk-0000uF-Ct for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Sep 2017 15:27:48 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 14 Sep 2017 15:27:40 +1000
Date: Thu, 14 Sep 2017 15:27:40 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170914052740.GA2674@erisian.com.au>
References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com>
<cb968a34-f8d2-ab61-dd15-9bd282afd18c@mattcorallo.com>
<20170911021506.GA19080@erisian.com.au>
<CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>
<20170912033703.GD19080@erisian.com.au>
<CAKzdR-oYQ8EchpJVE56yJbfBgNHihx7WO_gtFtp6QKOcK7uT-w@mail.gmail.com>
<e28e151a-1a67-4e90-f5fd-721cbc7f213d@bitcartel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e28e151a-1a67-4e90-f5fd-721cbc7f213d@bitcartel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: 0.6
X-Spam-Score-int: 6
X-Spam-Bar: /
X-Spam-Status: No, score=2.5 required=5.0 tests=RP_MATCHES_RCVD,
UNPARSEABLE_RELAY,URIBL_DBL_SPAM autolearn=disabled version=3.3.1
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 05:27:52 -0000
On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu wrote:
> It would be a good starting point if the current policy could be
> clarified, so everyone is on the same page, and there is no confusion.
Collecting various commentary from here and reddit, I think current de
facto policy is something like:
* Vulnerabilities should be reported via security@bitcoincore.org [0]
* A critical issue (that can be exploited immediately or is already
being exploited causing large harm) will be dealt with by:
* a released patch ASAP
* wide notification of the need to upgrade (or to disable affected
systems)
* minimal disclosure of the actual problem, to delay attacks
[1] [2]
* A non-critical vulnerability (because it is difficult or expensive to
exploit) will be dealt with by:
* patch and review undertaken in the ordinary flow of development
* backport of a fix or workaround from master to the current
released version [2]
* Devs will attempt to ensure that publication of the fix does not
reveal the nature of the vulnerability by providing the proposed fix
to experienced devs who have not been informed of the vulnerability,
telling them that it fixes a vulnerability, and asking them to identify
the vulnerability. [2]
* Devs may recommend other bitcoin implementations adopt vulnerability
fixes prior to the fix being released and widely deployed, if they
can do so without revealing the vulnerability; eg, if the fix has
significant performance benefits that would justify its inclusion. [3]
* Prior to a vulnerability becoming public, devs will generally recommend
to friendly altcoin devs that they should catch up with fixes. But this
is only after the fixes are widely deployed in the bitcoin network. [4]
* Devs will generally not notify altcoin developers who have behaved
in a hostile manner (eg, using vulnerabilities to attack others, or
who violate embargoes). [5]
* Bitcoin devs won't disclose vulnerability details until >80% of bitcoin
nodes have deployed the fixes. Vulnerability discovers are encouraged
and requested to follow the same policy. [1] [6]
Those seem like pretty good policies to me, for what it's worth.
I haven't seen anything that indicates bitcoin devs will *ever* encourage
public disclosure of vulnerabilities (as opposed to tolerating other
people publishing them [6]). So I'm guessing current de facto policy is
more along the lines of:
* Where possible, Bitcoin devs will never disclose vulnerabilities
publically while affected code may still be in use (including by
altcoins).
rather than something like:
* Bitcoin devs will disclose vulnerabilities publically after 99% of the
bitcoin network has upgraded [7], and fixes have been released for
at least 12 months.
Instinctively, I'd say documenting this policy (or whatever it actually
is) would be good, and having all vulnerabilities get publically released
eventually would also be good; that's certainly the more "open source"
approach. But arguing the other side:
- documenting security policy gives attackers a better handle on where
to find weak points; this may be more harm than there is benefit to
improving legitimate users' understanding of and confidence in the
development process
- the main benefit of public vulnerability disclosure is a better
working relationship with security researchers and perhaps better
understanding of what sort of bugs happen in practice in general;
but if most of your security research is effectively in house [6],
maybe those benefits aren't as great as the harm done by revealing
even old vulnerabilities to attackers
If the first of those arguments holds, well, hopefully this message has
egregious errors that no one will correct, or it will quickly get lost
in this list's archives...
Cheers,
aj
[0] http://bitcoincore.org/en/contact
referenced from .github/ISSUE_TEMPLATE.md in git
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014986.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014990.html
[3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nicely_pulled_away_attention_from_jjs/dmxcw70/
[4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_jj_discloses_bitcoin_attack_vector/dmxdg83/
[5] https://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_core_sat_on_vulnerability/dmv4y7g/
[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014991.html
[7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
it seems like 1.7% of the network is running known-vulnerable versions
0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that might argue
revealing any vulnerabilities fixed since 0.12.0 would be fine...
(bitnodes.21.co doesn't seem to break down anything earlier than 0.12)
|
