From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ABBBD9AF for ; Fri, 22 Sep 2017 02:00:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6AF1B4AF for ; Fri, 22 Sep 2017 02:00:32 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id k101so31801iod.0 for ; Thu, 21 Sep 2017 19:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z.cash; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+OjjPW1Nty+UjaDADOVKG9L5tOjGUIljSLtBQj05Ybs=; b=hBBzalEyeK9eM8Osj0riB05af9QSUfeDd0wrwyu/4zelovjmDYCc3/BKPZnriVaHKU W1ajbZQepUzsIK99bWBgv8e7/xLR419KC4ynsU1UDHaSrkY/f6cUTiwz8V0g9Jt4+7cB +X+bkd/jD5ALGBHoGRYrzUO3UZDzh6xcpkVbxL5SkWPY9TzuFvgL+THEyk/geMf9BaUq E+BGm/mIkIvHtbE4IvI5fpcMJLsCvqVI/HMT3b3z6clsEZj9s9t96jHV7QWZhAFJcMb4 SaHuI/VO+emMHLulQblh1yCQtbCXiHPNQJU7k+ilINIUGbgSUEsCZ/Sn7CUk9P2XZILF nqMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+OjjPW1Nty+UjaDADOVKG9L5tOjGUIljSLtBQj05Ybs=; b=n7M//UVmnkbHqwJCqFCmgYHavs51CEUmPXQ5iF377SkVSAP8IpJ9rm0OxVlJqpv1vK NGTmcs6yL5yGdrG6bJybusbP5twUXRxaprWei2F+T/1irzfIEybtgRJusXHNem5bewMF 5QfYlYtdVcCw4GUgKPVa1B1AovzmPNF9Qq4JQEClsbvUl0EIaMzqvizE4d29UpyHum+7 wQaLsgkHDxVkIsJdZ2+1lmR827eUTHwpHUWc2Zs1W7VIEW05loel9sPaxzpmjO/rqvYB /uvU65ZKEgivwVczFSP3AtfZ6LBbXaAzW2HqYA6KjBNTDW38m3fOjjBWsDESggv8vhJ0 i4eg== X-Gm-Message-State: AHPjjUhRjz52cvIiEvmk6+owPNq/kTiq33XhlQPtv+4/OucjSYBqpxQ3 BirrshPK5NxgXUaSy09LohXW3afHBQ3rDXvQvIhsiA== X-Google-Smtp-Source: AOwi7QCCkgJeDzFObw8saNcQUNsMaa22s+LaXpni02mnuRTxnRhj3y8QlFDYpp9Cn1xv5KzGf9PsB3rMv/AaXNGNpYE= X-Received: by 10.202.231.13 with SMTP id e13mr185470oih.49.1506045631671; Thu, 21 Sep 2017 19:00:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.48.133 with HTTP; Thu, 21 Sep 2017 19:00:31 -0700 (PDT) In-Reply-To: <20170914052740.GA2674@erisian.com.au> References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com> <20170911021506.GA19080@erisian.com.au> <20170912033703.GD19080@erisian.com.au> <20170914052740.GA2674@erisian.com.au> From: Nathan Wilcox Date: Fri, 22 Sep 2017 11:00:31 +0900 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1141b37ee43f290559bd92c6" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,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 X-Mailman-Approved-At: Fri, 22 Sep 2017 02:02:14 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 02:00:33 -0000 --001a1141b37ee43f290559bd92c6 Content-Type: text/plain; charset="UTF-8" [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 > --001a1141b37ee43f290559bd92c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[inline responses]


<= div class=3D"gmail_quote">On Thu, Sep 14, 2017 at 2:27 PM, Anthony Towns vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= span class=3D"gmail-">On Tue, Sep 12, 2017 at 09:10:18AM -0700, Simon Liu w= rote:
> 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:

=C2=A0* Vulnerabilities should be reported via security@bitcoincore.org [0]

=C2=A0* A critical issue (that can be exploited immediately or is already =C2=A0 =C2=A0being exploited causing large harm) will be dealt with by:
=C2=A0 =C2=A0 =C2=A0* a released patch ASAP
=C2=A0 =C2=A0 =C2=A0* wide notification of the need to upgrade (or to disab= le affected
=C2=A0 =C2=A0 =C2=A0 =C2=A0systems)
=C2=A0 =C2=A0 =C2=A0* minimal disclosure of the actual problem, to delay at= tacks
=C2=A0 =C2=A0[1] [2]

=C2=A0* A non-critical vulnerability (because it is difficult or expensive = to
=C2=A0 =C2=A0exploit) will be dealt with by:
=C2=A0 =C2=A0 =C2=A0* patch and review undertaken in the ordinary flow of d= evelopment
=C2=A0 =C2=A0 =C2=A0* backport of a fix or workaround from master to the cu= rrent
=C2=A0 =C2=A0 =C2=A0 =C2=A0released version [2]

=C2=A0* Devs will attempt to ensure that publication of the fix does not =C2=A0 =C2=A0reveal the nature of the vulnerability by providing the propos= ed fix
=C2=A0 =C2=A0to experienced devs who have not been informed of the vulnerab= ility,
=C2=A0 =C2=A0telling them that it fixes a vulnerability, and asking them to= identify
=C2=A0 =C2=A0the vulnerability. [2]

=C2=A0* Devs may recommend other bitcoin implementations adopt vulnerabilit= y
=C2=A0 =C2=A0fixes prior to the fix being released and widely deployed, if = they
=C2=A0 =C2=A0can do so without revealing the vulnerability; eg, if the fix = has
=C2=A0 =C2=A0significant performance benefits that would justify its inclus= ion. [3]

=C2=A0* Prior to a vulnerability becoming public, devs will generally recom= mend
=C2=A0 =C2=A0to friendly altcoin devs that they should catch up with fixes.= But this
=C2=A0 =C2=A0is only after the fixes are widely deployed in the bitcoin net= work. [4]

=C2=A0* Devs will generally not notify altcoin developers who have behaved<= br> =C2=A0 =C2=A0in a hostile manner (eg, using vulnerabilities to attack other= s, or
=C2=A0 =C2=A0who violate embargoes). [5]

=C2=A0* Bitcoin devs won't disclose vulnerability details until >80%= of bitcoin
=C2=A0 =C2=A0nodes have deployed the fixes. Vulnerability discovers are enc= ouraged
=C2=A0 =C2=A0and 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 prop= ose two modifications:

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

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

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

Imagine if altcoin X is=20 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=20 dumb luck. In the other case, if the Bitcoin disclosure reveals that X=20 was indeed contacted early, then it probably indicates incompetence of=20 the altoin X.

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

=C2=A0
I haven't seen anything that indicates bitcoin devs will *ever* encoura= ge
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:

=C2=A0* Where possible, Bitcoin devs will never disclose vulnerabilities =C2=A0 =C2=A0publically while affected code may still be in use (including = by
=C2=A0 =C2=A0altcoins).

rather than something like:

=C2=A0* Bitcoin devs will disclose vulnerabilities publically after 99% of = the
=C2=A0 =C2=A0bitcoin network has upgraded [7], and fixes have been released= for
=C2=A0 =C2=A0at least 12 months.


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

Ha= ving 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=20 knowledge, a precious public good.
=C2=A0

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 sou= rce"
approach. But arguing the other side:

=C2=A0- documenting security policy gives attackers a better handle on wher= e
=C2=A0 =C2=A0to find weak points; this may be more harm than there is benef= it to
=C2=A0 =C2=A0improving legitimate users' understanding of and confidenc= e in the
=C2=A0 =C2=A0development 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 t= he benefit is good for users and developers.

=C2=A0
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
=C2=A0
[0] http://bitcoincore.org/en/contact
=C2=A0 =C2=A0 referenced from .github/ISSUE_TEMPLATE.md in git

[1] https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014986.h= tml

[2] https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014990.h= tml

[3] https://www.reddit.com/r/btc/comments/6zf1qo/peter_todd_nic= ely_pulled_away_attention_from_jjs/dmxcw70/

[4] https://www.reddit.com/r/btc/comments/6z827o/chris_jeffrey_= jj_discloses_bitcoin_attack_vector/dmxdg83/

[5] ht= tps://www.reddit.com/r/btc/comments/6zb3lp/maxwell_admits_core_sa= t_on_vulnerability/dmv4y7g/

[6] https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014991.h= tml

[7] Per http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
=C2=A0 =C2=A0 it seems like 1.7% of the network is running known-vulnerable= versions
=C2=A0 =C2=A0 0.8 and 0.9; but only 0.37% are running 0.10 or 0.11, so that= might argue
=C2=A0 =C2=A0 revealing any vulnerabilities fixed since 0.12.0 would be fin= e...
=C2=A0 =C2=A0 (bitnodes.21.co doesn't seem to break down anything earl= ier than 0.12)

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a1141b37ee43f290559bd92c6--