public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Daniel Stadulis <dstadulis@gmail.com>
To: Alex Morcos <morcos@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Responsible disclosure of bugs
Date: Mon, 11 Sep 2017 10:43:52 -0700	[thread overview]
Message-ID: <CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com> (raw)
In-Reply-To: <CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2017-09-11 17:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-10 22:03 [bitcoin-dev] Responsible disclosure of bugs 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 [this message]
2017-09-11 18:29         ` Gregory Maxwell
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='CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com' \
    --to=dstadulis@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=morcos@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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