Daniel Stadulis [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-11 📝 Original message:I think it's relevant to ...
📅 Original date posted:2017-09-11
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/06bf75a1/attachment.html>;
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/06bf75a1/attachment.html>;