[bitcoin-dev] Responsible disclosure of bugs

[bitcoin-dev] Responsible disclosure of bugs

[Simon Liu]

Hi,

Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
conference, and the subsequent discussion around responsible disclosure
and industry practice, perhaps now would be a good time to discuss
"Bitcoin and CVEs" which has gone unanswered for 6 months.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013751.html

To quote:

"Are there are any vulnerabilities in Bitcoin which have been fixed but
not yet publicly disclosed?  Is the following list of Bitcoin CVEs
up-to-date?

https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

There have been no new CVEs posted for almost three years, except for
CVE-2015-3641, but there appears to be no information publicly available
for that issue:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641

It would be of great benefit to end users if the community of clients
and altcoins derived from Bitcoin Core could be patched for any known
vulnerabilities.

Does anyone keep track of security related bugs and patches, where the
defect severity is similar to those found on the CVE list above?  If
yes, can that list be shared with other developers?"

Best Regards,
Simon

Re: [bitcoin-dev] Responsible disclosure of bugs

[Matt Corallo]

I believe there continues to be concern over a number of altcoins which
are running old, unpatched forks of Bitcoin Core, making it rather
difficult to disclose issues without putting people at risk (see, eg,
some of the dos issues which are preventing release of the alert key).
I'd encourage the list to have a discussion about what reasonable
approaches could be taken there.

On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> Hi,
> 
> Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> conference, and the subsequent discussion around responsible disclosure
> and industry practice, perhaps now would be a good time to discuss
> "Bitcoin and CVEs" which has gone unanswered for 6 months.
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013751.html
> 
> To quote:
> 
> "Are there are any vulnerabilities in Bitcoin which have been fixed but
> not yet publicly disclosed?  Is the following list of Bitcoin CVEs
> up-to-date?
> 
> https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> 
> There have been no new CVEs posted for almost three years, except for
> CVE-2015-3641, but there appears to be no information publicly available
> for that issue:
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> 
> It would be of great benefit to end users if the community of clients
> and altcoins derived from Bitcoin Core could be patched for any known
> vulnerabilities.
> 
> Does anyone keep track of security related bugs and patches, where the
> defect severity is similar to those found on the CVE list above?  If
> yes, can that list be shared with other developers?"
> 
> Best Regards,
> Simon
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Responsible disclosure of bugs

[CryptAxe]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

I don't think we should put any Bitcoin users at additional risk to help
altcoins. If they fork the code they are making maintenance their own
responsibly.

It's hard to disclose a bitcoin vulnerability considering the network is
decentralised and core can't force everyone to update. Maybe a timeout
period for vulnerabilities could be decided. People might be expected to
patched before then at which point the vulnerability can be published. Is
that not already sort of how it works?

On Sep 10, 2017 4:10 PM, "Matt Corallo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I believe there continues to be concern over a number of altcoins which
> are running old, unpatched forks of Bitcoin Core, making it rather
> difficult to disclose issues without putting people at risk (see, eg,
> some of the dos issues which are preventing release of the alert key).
> I'd encourage the list to have a discussion about what reasonable
> approaches could be taken there.
>
> On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > Hi,
> >
> > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > conference, and the subsequent discussion around responsible disclosure
> > and industry practice, perhaps now would be a good time to discuss
> > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> >
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013751.html
> >
> > To quote:
> >
> > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > not yet publicly disclosed?  Is the following list of Bitcoin CVEs
> > up-to-date?
> >
> > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> >
> > There have been no new CVEs posted for almost three years, except for
> > CVE-2015-3641, but there appears to be no information publicly available
> > for that issue:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> >
> > It would be of great benefit to end users if the community of clients
> > and altcoins derived from Bitcoin Core could be patched for any known
> > vulnerabilities.
> >
> > Does anyone keep track of security related bugs and patches, where the
> > defect severity is similar to those found on the CVE list above?  If
> > yes, can that list be shared with other developers?"
> >
> > Best Regards,
> > Simon
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4113 bytes --]

Re: [bitcoin-dev] Responsible disclosure of bugs

[Anthony Towns]

On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev wrote:
> I believe there continues to be concern over a number of altcoins which
> are running old, unpatched forks of Bitcoin Core, making it rather
> difficult to disclose issues without putting people at risk (see, eg,
> some of the dos issues which are preventing release of the alert key).
> I'd encourage the list to have a discussion about what reasonable
> approaches could be taken there.

That seems like it just says bitcoin core has two classes of users:
people who use it directly following mainnet or testnet, and people who
make derived works based on it to run altcoins.

Having a "responsible disclosure" timeline something like:

 * day -N: vulnerability reported privately
 * day -N+1: details shared amongst private trusted bitcoin core group
 * day 0: patch/workaround/mitigation determined, CVE reserved
 * day 1: basic information shared with small group of trusted users
      (eg, altcoin maintainers, exchanges, maybe wallet devs)
 * day ~7: patches can be included in git repo
      (without references to vulnerability)
 * day 90: release candidate with fix available
 * day 120: official release including fix
 * day 134: CVE published with details and acknowledgements

could make sense. 90 days / 3 months is hopefully a fair strict upper
bound for how long it should take to get a fix into a rc; but that's still
a lot longer than many responsible disclosure timeframes, like CERT's at
45 days, but also shorter than some bitcoin core minor update cycles...
Obviously, those timelines could be varied down if something is more
urgent (or just easy).

As it is, not publishing vulnerability info just seems like it gives
everyone a false sense of security, and encourages ignoring good security
practices, either not upgrading bitcoind nodes, or not ensuring altcoin
implementations keep up to date...

I suppose both "trusted bitcoin core group" and "small group of trusted
users" isn't 100% cypherpunk, but it sure seems better than not both not
disclosing vulnerability details, and not disclosing vulnerabilities
at all... (And maybe it could be made more cypherpunk by, say, having
the disclosures to trusted groups have the description/patches get
automatically fuzzed to perhaps allow identification of leakers?)

Cheers,
aj

> On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > Hi,
> > 
> > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > conference, and the subsequent discussion around responsible disclosure
> > and industry practice, perhaps now would be a good time to discuss
> > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> > 
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013751.html
> > 
> > To quote:
> > 
> > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > not yet publicly disclosed?  Is the following list of Bitcoin CVEs
> > up-to-date?
> > 
> > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> > 
> > There have been no new CVEs posted for almost three years, except for
> > CVE-2015-3641, but there appears to be no information publicly available
> > for that issue:
> > 
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> > 
> > It would be of great benefit to end users if the community of clients
> > and altcoins derived from Bitcoin Core could be patched for any known
> > vulnerabilities.
> > 
> > Does anyone keep track of security related bugs and patches, where the
> > defect severity is similar to those found on the CVE list above?  If
> > yes, can that list be shared with other developers?"
> > 
> > Best Regards,
> > Simon
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Responsible disclosure of bugs

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 5204 bytes --]

I don't think I know the right answer here, but I will point out two things
that make this a little more complicated.

1 - There are lots of altcoin developers and while I'm sure the majority
would greatly appreciate the disclosure and would behave responsibly with
the information, I don't know where you draw the line on who you tell and
who you don't.

2- Unlike other software, I'm not sure good security for bitcoin is defined
by constant upgrading.  Obviously upgrading has an important benefit, but
one of the security considerations for Bitcoin is knowing that your
definition of the money hasn't changed.  Much harder to know that if you
change software.



On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > I believe there continues to be concern over a number of altcoins which
> > are running old, unpatched forks of Bitcoin Core, making it rather
> > difficult to disclose issues without putting people at risk (see, eg,
> > some of the dos issues which are preventing release of the alert key).
> > I'd encourage the list to have a discussion about what reasonable
> > approaches could be taken there.
>
> That seems like it just says bitcoin core has two classes of users:
> people who use it directly following mainnet or testnet, and people who
> make derived works based on it to run altcoins.
>
> Having a "responsible disclosure" timeline something like:
>
>  * day -N: vulnerability reported privately
>  * day -N+1: details shared amongst private trusted bitcoin core group
>  * day 0: patch/workaround/mitigation determined, CVE reserved
>  * day 1: basic information shared with small group of trusted users
>       (eg, altcoin maintainers, exchanges, maybe wallet devs)
>  * day ~7: patches can be included in git repo
>       (without references to vulnerability)
>  * day 90: release candidate with fix available
>  * day 120: official release including fix
>  * day 134: CVE published with details and acknowledgements
>
> could make sense. 90 days / 3 months is hopefully a fair strict upper
> bound for how long it should take to get a fix into a rc; but that's still
> a lot longer than many responsible disclosure timeframes, like CERT's at
> 45 days, but also shorter than some bitcoin core minor update cycles...
> Obviously, those timelines could be varied down if something is more
> urgent (or just easy).
>
> As it is, not publishing vulnerability info just seems like it gives
> everyone a false sense of security, and encourages ignoring good security
> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
> implementations keep up to date...
>
> I suppose both "trusted bitcoin core group" and "small group of trusted
> users" isn't 100% cypherpunk, but it sure seems better than not both not
> disclosing vulnerability details, and not disclosing vulnerabilities
> at all... (And maybe it could be made more cypherpunk by, say, having
> the disclosures to trusted groups have the description/patches get
> automatically fuzzed to perhaps allow identification of leakers?)
>
> Cheers,
> aj
>
> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > > Hi,
> > >
> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > > conference, and the subsequent discussion around responsible disclosure
> > > and industry practice, perhaps now would be a good time to discuss
> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> > >
> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013751.html
> > >
> > > To quote:
> > >
> > > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > > not yet publicly disclosed?  Is the following list of Bitcoin CVEs
> > > up-to-date?
> > >
> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> > >
> > > There have been no new CVEs posted for almost three years, except for
> > > CVE-2015-3641, but there appears to be no information publicly
> available
> > > for that issue:
> > >
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> > >
> > > It would be of great benefit to end users if the community of clients
> > > and altcoins derived from Bitcoin Core could be patched for any known
> > > vulnerabilities.
> > >
> > > Does anyone keep track of security related bugs and patches, where the
> > > defect severity is similar to those found on the CVE list above?  If
> > > yes, can that list be shared with other developers?"
> > >
> > > Best Regards,
> > > Simon
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7252 bytes --]

Re: [bitcoin-dev] Responsible disclosure of bugs

[Daniel Stadulis]

[-- Attachment #1: Type: text/plain, Size: 6082 bytes --]

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

On Mon, Sep 11, 2017 at 4:34 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't think I know the right answer here, but I will point out two
> things that make this a little more complicated.
>
> 1 - There are lots of altcoin developers and while I'm sure the majority
> would greatly appreciate the disclosure and would behave responsibly with
> the information, I don't know where you draw the line on who you tell and
> who you don't.
>
> 2- Unlike other software, I'm not sure good security for bitcoin is
> defined by constant upgrading.  Obviously upgrading has an important
> benefit, but one of the security considerations for Bitcoin is knowing that
> your definition of the money hasn't changed.  Much harder to know that if
> you change software.
>
>
>
> On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
>> wrote:
>> > I believe there continues to be concern over a number of altcoins which
>> > are running old, unpatched forks of Bitcoin Core, making it rather
>> > difficult to disclose issues without putting people at risk (see, eg,
>> > some of the dos issues which are preventing release of the alert key).
>> > I'd encourage the list to have a discussion about what reasonable
>> > approaches could be taken there.
>>
>> That seems like it just says bitcoin core has two classes of users:
>> people who use it directly following mainnet or testnet, and people who
>> make derived works based on it to run altcoins.
>>
>> Having a "responsible disclosure" timeline something like:
>>
>>  * day -N: vulnerability reported privately
>>  * day -N+1: details shared amongst private trusted bitcoin core group
>>  * day 0: patch/workaround/mitigation determined, CVE reserved
>>  * day 1: basic information shared with small group of trusted users
>>       (eg, altcoin maintainers, exchanges, maybe wallet devs)
>>  * day ~7: patches can be included in git repo
>>       (without references to vulnerability)
>>  * day 90: release candidate with fix available
>>  * day 120: official release including fix
>>  * day 134: CVE published with details and acknowledgements
>>
>> could make sense. 90 days / 3 months is hopefully a fair strict upper
>> bound for how long it should take to get a fix into a rc; but that's still
>> a lot longer than many responsible disclosure timeframes, like CERT's at
>> 45 days, but also shorter than some bitcoin core minor update cycles...
>> Obviously, those timelines could be varied down if something is more
>> urgent (or just easy).
>>
>> As it is, not publishing vulnerability info just seems like it gives
>> everyone a false sense of security, and encourages ignoring good security
>> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
>> implementations keep up to date...
>>
>> I suppose both "trusted bitcoin core group" and "small group of trusted
>> users" isn't 100% cypherpunk, but it sure seems better than not both not
>> disclosing vulnerability details, and not disclosing vulnerabilities
>> at all... (And maybe it could be made more cypherpunk by, say, having
>> the disclosures to trusted groups have the description/patches get
>> automatically fuzzed to perhaps allow identification of leakers?)
>>
>> Cheers,
>> aj
>>
>> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
>> > > Hi,
>> > >
>> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
>> > > conference, and the subsequent discussion around responsible
>> disclosure
>> > > and industry practice, perhaps now would be a good time to discuss
>> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
>> > >
>> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -March/013751.html
>> > >
>> > > To quote:
>> > >
>> > > "Are there are any vulnerabilities in Bitcoin which have been fixed
>> but
>> > > not yet publicly disclosed?  Is the following list of Bitcoin CVEs
>> > > up-to-date?
>> > >
>> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
>> > >
>> > > There have been no new CVEs posted for almost three years, except for
>> > > CVE-2015-3641, but there appears to be no information publicly
>> available
>> > > for that issue:
>> > >
>> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
>> > >
>> > > It would be of great benefit to end users if the community of clients
>> > > and altcoins derived from Bitcoin Core could be patched for any known
>> > > vulnerabilities.
>> > >
>> > > Does anyone keep track of security related bugs and patches, where the
>> > > defect severity is similar to those found on the CVE list above?  If
>> > > yes, can that list be shared with other developers?"
>> > >
>> > > Best Regards,
>> > > Simon
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev@lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 8728 bytes --]

Re: [bitcoin-dev] Responsible disclosure of bugs

[Gregory Maxwell]

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.

Re: [bitcoin-dev] Responsible disclosure of bugs

[Anthony Towns]

On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans. 

That makes sense.

For comparison, Monero defines a response process that has three levels
and varies the response for each:

]     a. HIGH: impacts network as a whole, has potential to break entire
]        network, results in the loss of monero, or is on a scale of great
]        catastrophe
]     b. MEDIUM: impacts individual nodes, wallets, or must be carefully
]        exploited
]     c. LOW: is not easily exploitable

 -- https://github.com/monero-project/monero/blob/master/VULNERABILITY_RESPONSE_PROCESS.md

Among other things, HIGH gets treated as an emergency, MEDIUM get fixed
in a point release; LOW get deferred to the next regular release eg.

Additionally, independently of the severity, Monero's doc says they'll
either get their act together with a fix and report within 90 days,
or otherwise the researcher that found the vulnerability has the right
to publically disclose the issue themselves...

I wouldn't say that's a perfect fit for bitcoin core (at a minimum, given
the size of the ecosystem and how much care needs to go into releases,
I think 90 days is probably too short), but it seems better than current
practice...

For comparison, if you're an altcoin developer or just bitcoin core user,
and are trying to work out whether the software you're using is secure;
if you do a quick google and end up at:

  https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

you might conclude that as long as you're running version 0.11 or later,
you're fine. That doesn't seem like an accurate conclusion for people
to draw; but if you're not tracking every commit/PR, how do you do any
better than that?

Maybe transitioning from keeping things private indefinitely to having
a public disclosure policy is tricky. Maybe it might work to build up to it,
something like:

  * We'll start releasing info about security vulnerabilities fixed in
    0.12.0 and earlier releases as of 2018-01-01
  * Then we'll continue with 0.13.0 and earlier as of 2018-03-01
  * Likewise for 0.14.0 as of 2018-05-01
  * Thereafter we'll adopt a regular policy at http://...

That or something like it at least gives people relying on older,
potentially vulnerable versions a realistic chance to privately prepare
and deploy any upgrades or fixes they've missed out on until now.

Cheers,
aj

Re: [bitcoin-dev] Responsible disclosure of bugs

[Anthony Towns]

On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> I don't think I know the right answer here, but I will point out two things
> that make this a little more complicated.
> 1 - There are lots of altcoin developers and while I'm sure the majority would
> greatly appreciate the disclosure and would behave responsibly with the
> information, I don't know where you draw the line on who you tell and who you
> don't.

If you can't pick even a small group that's trustworthy (top five by
market cap as a start [0]? or just major bitcoin wallets / exchanges /
alt node implementations?), then it still seems better to (eventually)
disclose publically than keep it unrevealed and let it be a potential
advantage for attackers against people who haven't upgraded for other
reasons?

I find it hard to imagine bitcoin's still obscure enough that people
aren't tracking git commit logs to use them as inspiration for attacks
on bitcoin users and businesses; at best I would have thought it'd
only be a few months of development time between a fix being proposed
as a PR or committed to master and black hats having the ability to
exploit it in users who are running older nodes. (Or for that matter,
being able to be exploited by otherwise legitimate bitcoin businesses
with an agenda to push, a strong financial motive behind that agenda,
and a legal team that says they'll get away with it)

> 2- Unlike other software, I'm not sure good security for bitcoin is defined by
> constant upgrading.  Obviously upgrading has an important benefit, but one of
> the security considerations for Bitcoin is knowing that your definition of the
> money hasn't changed.  Much harder to know that if you change software.

Isn't that just an argument for putting more effort into backporting
fixes/workarounds? (I don't see how you do that without essentially
publically disclosing which patches have a security impact -- "oh,
gosh, this patch gets a backport, I wonder if maybe it has security
implications...")

(In so far as bitcoin is a consensus system, there can sometimes be a
positive network effect, where having other people upgrade can help your
security, even if you don't upgrade; "herd immunity" if you will. That
way a new release going out to other people helps keep you safe, even
while you continue to maintain the same definition of money by not
upgrading at all)

If altcoin maintainers are inconvenienced by tracking bitcoin-core
updates, that would be an argument for them to contribute back to their
upstream to make their own job easier; either helping with backports,
or perhaps contributing to patches like PR#8994 might help.

All of those things seem like they'd help not just altcoins but bitcoin
investors/traders too, so it's not even a trade-off between classes of
bitcoin core users.  And if in the end various altcoins aren't able to
keep up with security fixes, that's probably valuable information to
provide to the market...

Cheers,
aj

[0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
    I've no idea which of those might have trustworthy devs to work with,
    but surely at least a couple do?

Re: [bitcoin-dev] Responsible disclosure of bugs

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

Historically people have published vulnerabilities in Bitcoin only after
>80% of the nodes have upgraded. This seems to be the general (but not
publicly stated) policy. If you're a core developer and you know better,
please correct me.

This means that:

- a critical vulnerability, like a remote code execution, will be patched
immediately (without disclosing the actual problem) and all participants
will be notified asap. This is no different from any other open source
project. An example of this case was the OpenSSL Heartbleed vulnerability
that affected Bitcoin.

- a non-critical vulnerability, either because miners only can exploit it
or because it requires vast resources to pull, may require a wait of years
before publication, after a vulnerability was found and reported. This is
because the "natural" node upgrade rate is slow.

It also implies that some times a researcher works hard to investigate a
vulnerability and later he finds out it was previously reported. It also
means that the researcher cannot report to alt-coins which have a different
policy.

This policy has nothing to do with a loyalty to Bitcoin Core (or in fact,
the two or so developers that actually receive the e-mails to
security@bitcoincore.org).

This is a policy that has simply proven to work to protect Bitcoiners. It
began long long ago.



On Tue, Sep 12, 2017 at 12:37 AM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> > I don't think I know the right answer here, but I will point out two
> things
> > that make this a little more complicated.
> > 1 - There are lots of altcoin developers and while I'm sure the majority
> would
> > greatly appreciate the disclosure and would behave responsibly with the
> > information, I don't know where you draw the line on who you tell and
> who you
> > don't.
>
> If you can't pick even a small group that's trustworthy (top five by
> market cap as a start [0]? or just major bitcoin wallets / exchanges /
> alt node implementations?), then it still seems better to (eventually)
> disclose publically than keep it unrevealed and let it be a potential
> advantage for attackers against people who haven't upgraded for other
> reasons?
>
> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks
> on bitcoin users and businesses; at best I would have thought it'd
> only be a few months of development time between a fix being proposed
> as a PR or committed to master and black hats having the ability to
> exploit it in users who are running older nodes. (Or for that matter,
> being able to be exploited by otherwise legitimate bitcoin businesses
> with an agenda to push, a strong financial motive behind that agenda,
> and a legal team that says they'll get away with it)
>
> > 2- Unlike other software, I'm not sure good security for bitcoin is
> defined by
> > constant upgrading.  Obviously upgrading has an important benefit, but
> one of
> > the security considerations for Bitcoin is knowing that your definition
> of the
> > money hasn't changed.  Much harder to know that if you change software.
>
> Isn't that just an argument for putting more effort into backporting
> fixes/workarounds? (I don't see how you do that without essentially
> publically disclosing which patches have a security impact -- "oh,
> gosh, this patch gets a backport, I wonder if maybe it has security
> implications...")
>
> (In so far as bitcoin is a consensus system, there can sometimes be a
> positive network effect, where having other people upgrade can help your
> security, even if you don't upgrade; "herd immunity" if you will. That
> way a new release going out to other people helps keep you safe, even
> while you continue to maintain the same definition of money by not
> upgrading at all)
>
> If altcoin maintainers are inconvenienced by tracking bitcoin-core
> updates, that would be an argument for them to contribute back to their
> upstream to make their own job easier; either helping with backports,
> or perhaps contributing to patches like PR#8994 might help.
>
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users.  And if in the end various altcoins aren't able to
> keep up with security fixes, that's probably valuable information to
> provide to the market...
>
> Cheers,
> aj
>
> [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin?
>     I've no idea which of those might have trustworthy devs to work with,
>     but surely at least a couple do?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6064 bytes --]

Re: [bitcoin-dev] Responsible disclosure of bugs

[Simon Liu]

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.


On 09/11/2017 09:49 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Historically people have published vulnerabilities in Bitcoin only after
>>80% of the nodes have upgraded. This seems to be the general (but not
> publicly stated) policy. If you're a core developer and you know better,
> please correct me.
> 

Re: [bitcoin-dev] Responsible disclosure of bugs

[Anthony Towns]

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)

Re: [bitcoin-dev] Responsible disclosure of bugs

[Nathan Wilcox]

[-- Attachment #1: Type: text/plain, Size: 8288 bytes --]

[inline responses]


On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 advocate a policy like this, except I propose two modifications:

- Point 4 should include *zero or more* altcoin developers, such that those
altcoins also deploy mitigations as early as Bitcoin. (Call this "early
altcoin disclosure".)

- Disclose of vulnerabilities, by social convention, always explicitly
names which altcoin developers were included in my proposed Early Altcoin
Disclosure and Point 6.

The rationale is that the policy should allow closer coordination with
altcoins. If the goal is minimizing economic damage, including altcoins
earlier may be the better trade-off between inclusiveness and secrecy. At
the same time, the policy doesn't establish *which* altcoins, which is a
tricky choice. However it *does* require disclosure of those relationships,
which provides a form of feedback on the system.

Imagine if altcoin X is compromised, and later disclosure occurs that
reveals that altcoin X was not contacted early, then this *might* indicate
leaks, maliciousness in the Bitcoin mitigation organization, or it *might*
be coincidence or dumb luck. In the other case, if the Bitcoin disclosure
reveals that X was indeed contacted early, then it probably indicates
incompetence of the altoin X.

Finally, notice that this kind of loose early disclosure policy can be
symmetric. For example, Zcash developers may choose to disclose
vulnerabilities they discover which affect Bitcoin to Bitcoin developers
*before* Zcash releases fixes, or before those fixes are widely adopted in
Zcash. We actually have a policy of doing this, since it's obvious that if
our mitigation process leaks and that's used to attack Bitcoin the
potential economic damage is very large.



> 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.
>
>
I advocate for something like the latter case. I'd like to see a timeout on
disclosure. There's an endless tail of alt-coins that could be affected,
and no guarantee all will vigilantly upgrade. Meanwhile, deciding which of
them to disclose to confidentially versus which should just receive hints
to apply new patches is tricky and political.

Having a global timeout is a reasonable stop-gap. I consider the cost of
never disclosing, publicly, a known vulnerbility to be very high, even if
the fix is ubiquitously deployed, because it's a loss of security
knowledge, a precious public good.


>
> 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
>
>
Publishing a policy *might* increase organizational vulnerability, but so
might *not publishing* a policy. It seems fairly neutral to me on
vulnerability impact, whereas the benefit is good for users and developers.



>  - 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
>
>
Publishing after a reasonable timeout has many benefits. Many security
researchers learn from vulnerability disclosures across many disciplines
and industries. Future protocol designers of things potentially unrelated
to blockchain altogether may also learn important lessons.


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
>
>
regards,
Nathan Wilcox
Zcash


> [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)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11733 bytes --]

Re: [bitcoin-dev] Responsible disclosure of bugs

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 10013 bytes --]

The policy seems good with the exception of this paragraph:

* 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.

99% upgrade may never be reached. Some nodes cannot even be categorized. I
suggest a number close to 95%.
If the 95% of network has upgraded, it means we're pretty secure from the
point of view of consensus. It is supposed that from the time the fix has
been released, all other alt-coins will also have released their fixes.
Remember we must also incentivize security researchers to do the hard and
silent research work. Most of them do not hold Bitcoins. They do research
because of other interests, including getting public acknowledgment for
their findings. They'll be frustrated if they have to wait 2 years.

I propose this paragraph to replace the previous one:

* Bitcoin devs will disclose vulnerabilities publically after 95% of the
   bitcoin network has upgraded [7], and fixes have been released for
   at least 6 months.

Also I suggest we track vulnerabilities with standard CVE codes. IS there
any drawback of this?

regards


On Thu, Sep 21, 2017 at 11:00 PM, Nathan Wilcox via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> [inline responses]
>
>
> On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 advocate a policy like this, except I propose two modifications:
>
> - Point 4 should include *zero or more* altcoin developers, such that
> those altcoins also deploy mitigations as early as Bitcoin. (Call this
> "early altcoin disclosure".)
>
> - Disclose of vulnerabilities, by social convention, always explicitly
> names which altcoin developers were included in my proposed Early Altcoin
> Disclosure and Point 6.
>
> The rationale is that the policy should allow closer coordination with
> altcoins. If the goal is minimizing economic damage, including altcoins
> earlier may be the better trade-off between inclusiveness and secrecy. At
> the same time, the policy doesn't establish *which* altcoins, which is a
> tricky choice. However it *does* require disclosure of those relationships,
> which provides a form of feedback on the system.
>
> Imagine if altcoin X is compromised, and later disclosure occurs that
> reveals that altcoin X was not contacted early, then this *might* indicate
> leaks, maliciousness in the Bitcoin mitigation organization, or it *might*
> be coincidence or dumb luck. In the other case, if the Bitcoin disclosure
> reveals that X was indeed contacted early, then it probably indicates
> incompetence of the altoin X.
>
> Finally, notice that this kind of loose early disclosure policy can be
> symmetric. For example, Zcash developers may choose to disclose
> vulnerabilities they discover which affect Bitcoin to Bitcoin developers
> *before* Zcash releases fixes, or before those fixes are widely adopted in
> Zcash. We actually have a policy of doing this, since it's obvious that if
> our mitigation process leaks and that's used to attack Bitcoin the
> potential economic damage is very large.
>
>
>
>> 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.
>>
>>
> I advocate for something like the latter case. I'd like to see a timeout
> on disclosure. There's an endless tail of alt-coins that could be affected,
> and no guarantee all will vigilantly upgrade. Meanwhile, deciding which of
> them to disclose to confidentially versus which should just receive hints
> to apply new patches is tricky and political.
>
> Having a global timeout is a reasonable stop-gap. I consider the cost of
> never disclosing, publicly, a known vulnerbility to be very high, even if
> the fix is ubiquitously deployed, because it's a loss of security
> knowledge, a precious public good.
>
>
>>
>> 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
>>
>>
> Publishing a policy *might* increase organizational vulnerability, but so
> might *not publishing* a policy. It seems fairly neutral to me on
> vulnerability impact, whereas the benefit is good for users and developers.
>
>
>
>>  - 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
>>
>>
> Publishing after a reasonable timeout has many benefits. Many security
> researchers learn from vulnerability disclosures across many disciplines
> and industries. Future protocol designers of things potentially unrelated
> to blockchain altogether may also learn important lessons.
>
>
> 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
>>
>>
> regards,
> Nathan Wilcox
> Zcash
>
>
>> [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_nice
>> ly_pulled_away_attention_from_jjs/dmxcw70/
>>
>> [4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_j
>> j_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/branche
>> s.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)
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 14993 bytes --]

Re: [bitcoin-dev] Responsible disclosure of bugs

[Gregory Maxwell]

On Tue, Sep 12, 2017 at 4:49 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> It also implies that some times a researcher works hard to investigate a
> vulnerability and later he finds out it was previously reported. It also
> means that the researcher cannot report to alt-coins which have a different
> policy.

I agree with your post, but wanted to make a point of clarification on
the use of "can't".

If someone wants to report something to the Bitcoin project we're
obviously at your mercy in how we handle it. If we disagree on the
handling approach we may try to talk you into a different position
based with a rational judgement based on our experience (or, if
justified, advice that we're likely to whine about your approach in
public). But if you still want to go also report a common issue to
something else with a different approach then you can. Even our
ire/whining can be avoided by a sincere effort to communicate and give
us an opportunity to mitigate harm.

That said, as mentioned, we'd encourage otherwise for issues that
warrant it-- and I think with cause enough that the reporter will
agree. So that is a different kind of "cant". :)

In Bitcoin the overwhelming majority of serious issues we've
encountered have been found by people I'd consider 'inside the
project' (frequent regular contributors who aren't seriously involved
in other things).  That hasn't been so obviously the case for other
open source projects that I've been involved with; but Bitcoin is
pretty good from a basic security perspective and finding additional
issues often requires specialized experience that few people outside
of the project regulars have (though some, like Sergio, clearly do).

I know through direct experience that both Mozilla and the Chrome
project fix _serious_ (like RCE bugs) issues based on internal
discoveries which they do not make public (apparently ever), though
they may coordinate with distributors on some of them.   (Some of
these experiences are also why I give the advice that you should not
consider any computer which has ever run a web browser to be strongly
secure...)

Re: [bitcoin-dev] Responsible disclosure of bugs

[Bryan Bishop]

On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users.  And if in the end various altcoins aren't able to
> keep up with security fixes, that's probably valuable information to
> provide to the market...

I have a reply to your point, but I want to clarify first that I am
not trying to provide any sort of criticism of your character, and to
any extent that my text is misinterpreted that way, that's entirely my
fault here. Anyway, here goes.

It's not enough to defend bitcoin and its users from active threats,
there is a more general responsibility to defend all kinds of users
and different software from many kinds of threats in whatever forms,
even if folks are using stupid and insecure software that you
personally don't maintain or contribute to or advocate for. Handling
knowledge of a vulnerability is a delicate matter and you might be
receiving knowledge with more serious direct or indirect impact than
originally described.

Besides the moral and ethical reasons to not unduly accelerate the
exploitation of a vulnerability, there is also a reputational
standpoint to consider, in that your position that your own (security)
work is credible is actually harmed by showing negative care for other
works by being first to publish either insecure software or knowledge
of a vulnerability. And sometimes the opposite is true: by not
disclosing knowledge of how a design is broken to someone inviting its
review, you're showing negative care in that way too, such as by
unintentionally encouraging the implementation of really bad ideas or
entirely novel misunderstandings of what you once thought were clear
concepts. So there is a difficult path to walk and especially in
security not all may be as it seems; caution is highly recommended.

Yes it would be good for "the market" to "get the signal" that
altcoins are insecure, and that some altcoin vendors are literally and
actively malicious entities, but I think everyone needs to take a step
back here and very carefully consider the color of their hats,
including those who advocate in the name of insecure downstream/forked
software.

The downside of the approach I've advocated for is that it requires
knowledge, thinking and outsmarting the red teams; I am certainly
aware of the allure of the approaches that involve absolutist
statements like "anything weak [including bitcoin if it does have
weaknesses] deserves to die and be actively exploited" but it's not
something I am interested in espousing...nor do I think it would be
healthy for this community to internalize that perspective. Instead we
should continue to work on highly defensible software, and keep
vigilant in regards to security. In "the [civilized] garden" I would
expect there to be a general understanding that people collaborate and
work together to build highly defensible evolving systems even if
there exists knowledge of vulnerabilities. But we shouldn't be
surprised when we don't go out of our way to contribute to
alternative/parasitic systems... and we shouldn't be encouraging each
other to actively bring about the eschaton by way of mishandling
knowledge of vulnerabilities...

I know these issues are difficult to get a handle on. Hopefully I've
provided some useful perspective.

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [bitcoin-dev] Responsible disclosure of bugs

[Gregory Maxwell]

On Tue, Sep 12, 2017 at 3:37 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> If you can't pick even a small group that's trustworthy

No.

> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks

For embargoed fixes we test the specific fixes against experienced
developers inside the project, handing them the proposed commit and
informing them that it fixes a vulnerability and asking them to
identify it.

This does not guarantee that the fix won't leak the issue, but in
virtually all cases in the past the issues we've dealt with would not
be made worse off being leaked in that way vs just making it public
outright.

If we had an issue that would be-- e.g. an RCE that could lead to
private key theft, we would likely handle it differently (e.g. making
a public notice to take sensitive systems offline before attempting
any fix).

>  I would have thought it'd
> only be a few months of development time between a fix being proposed
> as a PR or committed to master and black hats having the ability to
> exploit it in users who are running older nodes. (Or for that matter,
> being able to be exploited by otherwise legitimate bitcoin businesses
> with an agenda to push, a strong financial motive behind that agenda,
> and a legal team that says they'll get away with it)

History does not support your assumptions.

>> 2- Unlike other software, I'm not sure good security for bitcoin is defined by
>> constant upgrading.  Obviously upgrading has an important benefit, but one of
>> the security considerations for Bitcoin is knowing that your definition of the
>> money hasn't changed.  Much harder to know that if you change software.
>
> Isn't that just an argument for putting more effort into backporting
> fixes/workarounds?

Not really.  Any forced change still creates centralization,
dependence, and an opportunity for insecurity.

> (I don't see how you do that without essentially
> publically disclosing which patches have a security impact -- "oh,
> gosh, this patch gets a backport, I wonder if maybe it has security
> implications...")

That is a concern too, but our bar for backport fixes is low enough
that they're often able to include more serious fixes without calling
attention to them.

> (In so far as bitcoin is a consensus system, there can sometimes be a
> positive network effect, where having other people upgrade can help your
> security, even if you don't upgrade; "herd immunity" if you will.

This is true even outside of the consensus critical parts.  In the P2P
network other people upgrading can be protective.

> If altcoin maintainers are inconvenienced by tracking bitcoin-core
> updates, that would be an argument for them to contribute back to their

Sure, a few have. Most do not because they are either not focused on
software quality or consider themselves as having an adversarial
relationship with Bitcoin.

> keep up with security fixes, that's probably valuable information to
> provide to the market...

If you'd like to provide the sort of valuable information to the
market which may get you sued or targeted for harassment of physical
attack-- feel free. Don't ask the rest of us to do so.