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 1D2628DC for ; Mon, 11 Sep 2017 17:44:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 06F70E7 for ; Mon, 11 Sep 2017 17:44:13 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id y123so31142430iod.0 for ; Mon, 11 Sep 2017 10:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZYKEy2B83a8K3bJsYaHDT5MCTCOHA0GR4oELemEekDw=; b=Cy7jlobcnyVSlF4b6qYBuUcfEOhJhVm0AIdgbiQ/N9nRBxH/9T7OZgQc7bZD5BddCd 2EEjBBfxWrr+r8CxzdRCMMtVEP+Mii/hK3IkyKCUf9dBjiSCTnHtYCfgXpTLZcyMff+T 1Rq6GeW2UHAmelmq1Jxczs3YO+fKB3i/rOkqvWcVqJmmpN0bnbEZqmQmODW0FMysdzwK LrJOm7rNolB87027h0oOhDLD27DA8CwuM9++LRq391AHacGNfZWL0zxrehFnybSIv+Ea xNsRzCg4SzKxiu0BF+tPz8oUkSwic24dEpJhr71F0Uc2GqP21SvPVGTR2PS3sC3Hy056 WORA== 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:cc; bh=ZYKEy2B83a8K3bJsYaHDT5MCTCOHA0GR4oELemEekDw=; b=Vx5nDek3gLAStbCFTHAJ9vLJA1V5/J1l6cYatT3eVhs6UE5xzcv7ZUz/6N3e9eRLBY GAwl5+bqOAiwYt2/M2V+69ttOQCoNoZCxriDQWdqSAmLVTpRe6NVvARuYfLfGSmM5hYZ 6vk941hszpvUJpKhS0XvurSD7xJ+36rbmgwqkLa768lfBTOiZDaPo3DF6VlIAek5dW4e LTd26enYynDq3w9XJOfq0JcpJ79gdgTF1YkFSheRoIuDWFmR2TkHydNSPB4Cq5B450+h IrhtK7/KBm8Jo0l6EaBgBCk1cpUkw0EeyQtMDuqeB8+7s1UZnm/lb30Bm3Q93zQqS/xh BSoQ== X-Gm-Message-State: AHPjjUii4liLUf2C7VWunsT2JUbqjmP40eaZnDwfg0BZ/YHH1eQfOJG8 d96MgFydWG689ODygP+Y3j+Vyfm1zQ== X-Google-Smtp-Source: AOwi7QAqVbXB0hszux2K2uV1dXhJg29Mr39VQzMz4AQPiAUfRh6K0labukt9o7ChxUVRBneiR/ZBdZOIn6VLW4XzgBg= X-Received: by 10.202.196.195 with SMTP id u186mr399874oif.315.1505151852988; Mon, 11 Sep 2017 10:44:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.0.65 with HTTP; Mon, 11 Sep 2017 10:43:52 -0700 (PDT) In-Reply-To: References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com> <20170911021506.GA19080@erisian.com.au> From: Daniel Stadulis Date: Mon, 11 Sep 2017 10:43:52 -0700 Message-ID: To: Alex Morcos , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1135303487d12a0558ed798d" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 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: Mon, 11 Sep 2017 17:44:15 -0000 --001a1135303487d12a0558ed798d Content-Type: text/plain; charset="UTF-8" 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 > > --001a1135303487d12a0558ed798d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it's relevant to treat different bug severity = levels with different response plans.=C2=A0

E.g.
Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
Compromising UTXO state (In=C2=A0CVE-2013-3220, blockchain split du= e to Berkeley DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unsched= uled inflation of coins)
Compromising Node performance (Various n= ode-specific DoS attacks)

Should have different di= sclosure policies, IMO

On Mon, Sep 11, 2017 at 4:34 AM, Alex Morcos via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I don't th= ink 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 a= ltcoin developers and while I'm sure the majority would greatly appreci= ate 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.<= /div>

2- Unlike other software, I'm not sure good se= curity for bitcoin is defined by constant upgrading.=C2=A0 Obviously upgrad= ing has an important benefit, but one of the security considerations for Bi= tcoin is knowing that your definition of the money hasn't changed.=C2= =A0 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 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > Hi,
> >
> > Given today's presentation by Chris Jeffrey at the Breaking B= itcoin
> > conference, and the subsequent discussion around responsible disc= losure
> > and industry practice, perhaps now would be a good time to discus= s
> > "Bitcoin and CVEs" which has gone unanswered for 6 mont= hs.
> >
> > https://list= s.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013751.htm= l
> >
> > To quote:
> >
> > "Are there are any vulnerabilities in Bitcoin which have bee= n fixed but
> > not yet publicly disclosed?=C2=A0 Is the following list of Bitcoi= n 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 av= ailable
> > for that issue:
> >
> > https://cve.mitre.org/cgi-bi= n/cvename.cgi?name=3DCVE-2015-3641
> >
> > It would be of great benefit to end users if the community of cli= ents
> > and altcoins derived from Bitcoin Core could be patched for any k= nown
> > vulnerabilities.
> >
> > Does anyone keep track of security related bugs and patches, wher= e the
> > defect severity is similar to those found on the CVE list above?= =C2=A0 If
> > yes, can that list be shared with other developers?"
> >
> > Best Regards,
> > Simon
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.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


--001a1135303487d12a0558ed798d--