Re: [bitcoin-dev] Responsible disclosure of bugs

[Gregory Maxwell <greg@xiph.org>]

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.