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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 90448BDF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2017 18:29:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
[209.85.213.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E22D455
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2017 18:29:48 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id w23so1857017vkw.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2017 11:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=wOGn4i/yuZhIbZ4kEaeUTiu4GK2bsA9Y4Zkak+/kPmU=;
b=bSr9qoLorcrRCjw2pwiHUk46nUA7f7a13Kra5m1BEZ72G0aT7n+jscTP3bxqmFbRsd
3SmPSGuO/7h9p5ImunUNNq47sOsz2TOAZXSfe9xNi8uyoS9zINHX0kwhemL3UzFByT6F
cKxf9bp1vRSb2WGkZhMVGZDh+gkm4gPMK1F9MYwoswiMlL5WCP2YZk530BPQPohdqyZL
qF9kdldKEwQG6pN5HTFiffIrDgD3X8AMKZdJSMw8ymzNhlgQX9Iql+KQ92F0jZJ+nTyI
Drsul3ZocJQtzu/lQ6mzIQ0T0+rFWzRqZg8k08n6bJbtXbIZ830C6aSvefNTIaKIg5EN
qrFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=wOGn4i/yuZhIbZ4kEaeUTiu4GK2bsA9Y4Zkak+/kPmU=;
b=mSzy3zWCYP2/Sjc4+2X5ig/dAKhQva7zW9G6FEikM9Vh+IHwlyeSw01IzED+TWE+GF
AqMgQCiZoQIRNR88fSR3Ao8LqMjcMQAkmcJEiNu+u1MWZgz7RmElm9G7r8cTX/B+GGeo
En6w/HSSBxWDQCcJEqh2qJlMlmmV9eH6QEOCmpY9THC+tqtZdmViQ1986vdC4egO1A/J
YLADsvCvFIyX5Hy++YKJSfrQY7tGU3aAcZmmlgaA4FGUkcSritEDbTkG1QfsJ+TE3OM9
6W47MJGx9jMYCJurrs/rmYnspQOPIj1cJgj3zenRAoT/otpl1irGu02wwTVLPPsH72tK
Gm6A==
X-Gm-Message-State: AHPjjUhRnZKZLIHdF6OToqgMtRDCqQvJF7lhtLFIXgoBT3xDYl6BB9H8
2gYvF6rSgvNwEON7JCary7V9czOotw==
X-Google-Smtp-Source: AOwi7QBbGADuwOvkbjL5pWdXIzYx7SruFiieNqzFvGhKhcHciVso9h6Y+QLAUicLNnHKwv6B12sJ3dqaYxRqwJFn4zA=
X-Received: by 10.31.160.204 with SMTP id j195mr8852805vke.172.1505154587316;
Mon, 11 Sep 2017 11:29:47 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.146.78 with HTTP; Mon, 11 Sep 2017 11:29:46 -0700 (PDT)
In-Reply-To: <CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com>
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>
<CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Mon, 11 Sep 2017 18:29:46 +0000
X-Google-Sender-Auth: _e3tpdceiHHtMroR419E0jCTGF0
Message-ID: <CAAS2fgRD_poPjFaG6QD3L7R1GYKEO5LikrzXz+niBFBPbLCRQg@mail.gmail.com>
To: Daniel Stadulis <dstadulis@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled
version=3.3.1
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: Mon, 11 Sep 2017 18:29:48 -0000
On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
>
> E.g.
> Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
> Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley
> DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of
> coins)
> Compromising Node performance (Various node-specific DoS attacks)
>
> Should have different disclosure policies, IMO
This assumes the states are discernible. They often aren't cleanly.
You obviously know how bad it is in the best case, but the worst could
be much worse.
I've multiple time seen a hard to exploit issue turn out to be trivial
when you find the right trick, or a minor dos issue turn our to far
more serious.
Simple performance bugs, expertly deployed, can potentially be used to
carve up the network--- miner A and exchange B go in one partition,
everyone else in another.. and doublespend.
And so on. So while I absolutely do agree that different things
should and can be handled differently, it is not always so clear cut.
It's prudent to treat things as more severe than you know them to be.
In fact, someone pointed out to me a major amplifier of the
utxo-memory attack thing today that Bitcoin Core narrowly dodges which
would have made it very easy to exploit against some users, and which
it seems no one previously considered.
I also think it's somewhat incorrect to call this thread anything
about disclosure, this thread is not about disclosure. Disclosure is
when you tell the vendor. This thread is about publication and that
has very different implications. Publication is when you're sure
you've told the prospective attackers.
|
