path: root/3e/e66ac45d8142db37742abce5f8b61b4bf13fae

Return-Path: <dstadulis@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1D2628DC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Sep 2017 17:44:13 +0000 (UTC)
Received: by mail-io0-f169.google.com with SMTP id y123so31142430iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>
References: <3e4541f3-f65c-5199-5e85-9a65ea5142e7@bitcartel.com>
	<cb968a34-f8d2-ab61-dd15-9bd282afd18c@mattcorallo.com>
	<20170911021506.GA19080@erisian.com.au>
	<CAPWm=eVCh2FYp=SpOcZFLqz1ZCq3=Z_F9Sj+EAXFvqU-8aMuTg@mail.gmail.com>
From: Daniel Stadulis <dstadulis@gmail.com>
Date: Mon, 11 Sep 2017 10:43:52 -0700
Message-ID: <CAHpxFbH_5Pb5ZmNCW==fmZWxN3bH7KNjzJsMV5KJ=bjCPWMx6A@mail.gmail.com>
To: Alex Morcos <morcos@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">I think it&#39;s relevant to treat different bug severity =
levels with different response plans.=C2=A0<div><br></div><div>E.g.</div><d=
iv>Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)</d=
iv><div>Compromising UTXO state (In=C2=A0CVE-2013-3220, blockchain split du=
e to Berkeley DB -&gt; LevelDB upgrade, CVE-2010-5139 Overflow bug, unsched=
uled inflation of coins)</div><div>Compromising Node performance (Various n=
ode-specific DoS attacks)</div><div><br></div><div>Should have different di=
sclosure policies, IMO</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Sep 11, 2017 at 4:34 AM, Alex Morcos via bitcoin-d=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don&#39;t th=
ink I know the right answer here, but I will point out two things that make=
 this a little more complicated.<div><br></div><div>1 - There are lots of a=
ltcoin developers and while I&#39;m sure the majority would greatly appreci=
ate the disclosure and would behave responsibly with the information, I don=
&#39;t know where you draw the line on who you tell and who you don&#39;t.<=
/div><div><br></div><div>2- Unlike other software, I&#39;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&#39;t changed.=C2=
=A0 Much harder to know that if you change software.</div><div><br></div><d=
iv><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Sun, Sep 10, 2017 at 10:15 PM,=
 Anthony Towns via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr=
>linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span>On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-=
dev wrote:<br>
&gt; I believe there continues to be concern over a number of altcoins whic=
h<br>
&gt; are running old, unpatched forks of Bitcoin Core, making it rather<br>
&gt; difficult to disclose issues without putting people at risk (see, eg,<=
br>
&gt; some of the dos issues which are preventing release of the alert key).=
<br>
&gt; I&#39;d encourage the list to have a discussion about what reasonable<=
br>
&gt; approaches could be taken there.<br>
<br>
</span>That seems like it just says bitcoin core has two classes of users:<=
br>
people who use it directly following mainnet or testnet, and people who<br>
make derived works based on it to run altcoins.<br>
<br>
Having a &quot;responsible disclosure&quot; timeline something like:<br>
<br>
=C2=A0* day -N: vulnerability reported privately<br>
=C2=A0* day -N+1: details shared amongst private trusted bitcoin core group=
<br>
=C2=A0* day 0: patch/workaround/mitigation determined, CVE reserved<br>
=C2=A0* day 1: basic information shared with small group of trusted users<b=
r>
=C2=A0 =C2=A0 =C2=A0 (eg, altcoin maintainers, exchanges, maybe wallet devs=
)<br>
=C2=A0* day ~7: patches can be included in git repo<br>
=C2=A0 =C2=A0 =C2=A0 (without references to vulnerability)<br>
=C2=A0* day 90: release candidate with fix available<br>
=C2=A0* day 120: official release including fix<br>
=C2=A0* day 134: CVE published with details and acknowledgements<br>
<br>
could make sense. 90 days / 3 months is hopefully a fair strict upper<br>
bound for how long it should take to get a fix into a rc; but that&#39;s st=
ill<br>
a lot longer than many responsible disclosure timeframes, like CERT&#39;s a=
t<br>
45 days, but also shorter than some bitcoin core minor update cycles...<br>
Obviously, those timelines could be varied down if something is more<br>
urgent (or just easy).<br>
<br>
As it is, not publishing vulnerability info just seems like it gives<br>
everyone a false sense of security, and encourages ignoring good security<b=
r>
practices, either not upgrading bitcoind nodes, or not ensuring altcoin<br>
implementations keep up to date...<br>
<br>
I suppose both &quot;trusted bitcoin core group&quot; and &quot;small group=
 of trusted<br>
users&quot; isn&#39;t 100% cypherpunk, but it sure seems better than not bo=
th not<br>
disclosing vulnerability details, and not disclosing vulnerabilities<br>
at all... (And maybe it could be made more cypherpunk by, say, having<br>
the disclosures to trusted groups have the description/patches get<br>
automatically fuzzed to perhaps allow identification of leakers?)<br>
<br>
Cheers,<br>
aj<br>
<div class=3D"m_1222959791411789902HOEnZb"><div class=3D"m_1222959791411789=
902h5"><br>
&gt; On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; Given today&#39;s presentation by Chris Jeffrey at the Breaking B=
itcoin<br>
&gt; &gt; conference, and the subsequent discussion around responsible disc=
losure<br>
&gt; &gt; and industry practice, perhaps now would be a good time to discus=
s<br>
&gt; &gt; &quot;Bitcoin and CVEs&quot; which has gone unanswered for 6 mont=
hs.<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2017-March/013751.html" rel=3D"noreferrer" target=3D"_blank">https://list=
s.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/2017<wbr>-March/013751.htm=
l</a><br>
&gt; &gt;<br>
&gt; &gt; To quote:<br>
&gt; &gt;<br>
&gt; &gt; &quot;Are there are any vulnerabilities in Bitcoin which have bee=
n fixed but<br>
&gt; &gt; not yet publicly disclosed?=C2=A0 Is the following list of Bitcoi=
n CVEs<br>
&gt; &gt; up-to-date?<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_=
Exposures" rel=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/=
Com<wbr>mon_Vulnerabilities_and_Exposu<wbr>res</a><br>
&gt; &gt;<br>
&gt; &gt; There have been no new CVEs posted for almost three years, except=
 for<br>
&gt; &gt; CVE-2015-3641, but there appears to be no information publicly av=
ailable<br>
&gt; &gt; for that issue:<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2=
015-3641" rel=3D"noreferrer" target=3D"_blank">https://cve.mitre.org/cgi-bi=
n/<wbr>cvename.cgi?name=3DCVE-2015-3641</a><br>
&gt; &gt;<br>
&gt; &gt; It would be of great benefit to end users if the community of cli=
ents<br>
&gt; &gt; and altcoins derived from Bitcoin Core could be patched for any k=
nown<br>
&gt; &gt; vulnerabilities.<br>
&gt; &gt;<br>
&gt; &gt; Does anyone keep track of security related bugs and patches, wher=
e the<br>
&gt; &gt; defect severity is similar to those found on the CVE list above?=
=C2=A0 If<br>
&gt; &gt; yes, can that list be shared with other developers?&quot;<br>
&gt; &gt;<br>
&gt; &gt; Best Regards,<br>
&gt; &gt; Simon<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt; &gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a1135303487d12a0558ed798d--