From: Gregory Maxwell <greg@xiph•org>
To: Daniel Stadulis <dstadulis@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
Date: Mon, 11 Sep 2017 18:29:46 +0000 [thread overview]
Message-ID: <CAAS2fgRD_poPjFaG6QD3L7R1GYKEO5LikrzXz+niBFBPbLCRQg@mail.gmail.com> (raw)
In-Reply-To: <CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com>
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.
next prev parent reply other threads:[~2017-09-11 18:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-10 22:03 Simon Liu
2017-09-10 23:02 ` Matt Corallo
2017-09-10 23:28 ` CryptAxe
2017-09-11 2:15 ` Anthony Towns
2017-09-11 11:34 ` Alex Morcos
2017-09-11 17:43 ` Daniel Stadulis
2017-09-11 18:29 ` Gregory Maxwell [this message]
2017-09-12 4:47 ` Anthony Towns
2017-09-12 3:37 ` Anthony Towns
2017-09-12 4:49 ` Sergio Demian Lerner
2017-09-12 16:10 ` Simon Liu
2017-09-14 5:27 ` Anthony Towns
2017-09-22 2:00 ` Nathan Wilcox
2017-09-22 19:53 ` Sergio Demian Lerner
2017-09-12 17:57 ` Gregory Maxwell
2017-09-12 5:18 ` Bryan Bishop
2017-09-12 17:41 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgRD_poPjFaG6QD3L7R1GYKEO5LikrzXz+niBFBPbLCRQg@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dstadulis@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox