Re: [bitcoin-dev] Responsible disclosure of bugs
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/
Re: [bitcoin-dev] Responsible disclosure of bugs
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
Re: [bitcoin-dev] Responsible disclosure of bugs
On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev wrote: > 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 This assumes the states are discernible. They often aren't cleanly. You obviously know how bad it is in the best case, but the worst could be much worse. I've multiple time seen a hard to exploit issue turn out to be trivial when you find the right trick, or a minor dos issue turn our to far more serious. Simple performance bugs, expertly deployed, can potentially be used to carve up the network--- miner A and exchange B go in one partition, everyone else in another.. and doublespend. And so on. So while I absolutely do agree that different things should and can be handled differently, it is not always so clear cut. It's prudent to treat things as more severe than you know them to be. In fact, someone pointed out to me a major amplifier of the utxo-memory attack thing today that Bitcoin Core narrowly dodges which would have made it very easy to exploit against some users, and which it seems no one previously considered. I also think it's somewhat incorrect to call this thread anything about disclosure, this thread is not about disclosure. Disclosure is when you tell the vendor. This thread is about publication and that has very different implications. Publication is when you're sure you've told the prospective attackers. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST
Coincidentally, the kind of Merkle tree that Mark describes in his proposal is exactly the one that we use at Stampery. The Stampery BTA whitepaper[1] includes pseudocode for many of the algorithms outlined by this proposal, including fast-SHA256, the tree building process and the inclusion proving routine. The wording is slightly different but the logic is just the same, so I hope it helps future implementations in case of eventual adoption. [1] https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v6-whitepaper.pdf Best, -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid T: +34 663 163 375 signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST
My apologies for a delay in responding to emails on this list; I have been fighting a cold. (Also my apologies to Johnson Lau, as I forgot to forward this to the list.) On Sep 8, 2017, at 2:21 AM, Johnson Lau wrote: > Tail-call execution semantics require "unclean stake" , i.e. final > stake with more than one item. However, "unclean stake" is invalid > (not just non-standard) in BIP141, so you could only use it with > legacy P2SH (which is totally pointless). A different design > like OP_EVAL might be needed, or you need a new witness script > version. I believe you meant "unclean stack," and you are correct. This was also pointed out last tuesday by a participant at the in-person CoreDev meetup where the idea was presented. This doesn't kill the idea, it just complicates the implementation slightly. A simple fix would be to allow tail-recursion to occur if the stack is not clean (as can happen with legacy P2SH as you point out, or yet to be defined version 1+ forms of segwit script), OR if there is a single item on the stack and the alt-stack is not empty. For segwit v0 scripts you then have to move any arguments to the alt stack before ending the redeem script, leaving just the policy script on the main stack. > I think you have also missed the sigOp counting of the executed > script. As you can't count it without executing the script, the > current static analysability is lost. This was one of the reasons > for OP_EVAL being rejected. Since sigOp is a per-block limit, any > OP_EVAL-like operation means block validity will depend on the > precise outcome of script execution (instead of just pass or fail), > which is a layer violation. I disagree with this design requirement. The SigOp counting method used by bitcoin is flawed. It incorrectly limits not the number of signature operations necessary to validate a block, but rather the number of CHECKSIGs potentially encountered in script execution, even if in an unexecuted branch. (Admitedly MAST makes this less of an issue, but there are still useful compact scripts that use if/else constructs to elide a CHECKSIG.) Nor will it account for aggregation when that feature is added, or properly differentiate between signature operations that can be batched and those that can not. Additionally there are other resources used by script that should be globally limited, such as hash operations, which are not accounted for at this time and cannot be statically assessed, even by the flawed mechanism by which SigOps are counted. I have maintained for some time that bitcoin should move from having multiple separate global limits (weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear metric that combines all of these factors with appropriate coefficients. A better way of handling this problem, which works for both SigOps and HashOps, is to have the witness commit to the maximum resources consumed by validation of the spend of the coin, to relay this data with the transaction and include it in the SigHash, and to use the committed maximum for block validation. This could be added in a future script version upgrade. This change would also resolve the issue that led to the clean stack rule in segwit, allowing future versions of script to use tail-call recursion without involving the alt-stack. Nevertheless it is constructive feedback that the current draft of the BIP and its implementation do not count SigOps, at all. There are a couple of ways this can be fixed by evaluating the top-level script and then doing static analysis of the resulting policy script, or by running the script and counting operations actually performed. Additionally, it is possible that we take this time to re-evaluate whether we should be counting SigOps other than for legacy consensus rule compliance. The speed of verification in secp256k1 has made signature operations no longer the chief concern in block validation times. > Witness script versioning is by design fully compatible with P2SH > and BIP173, so there will be no hurdle for existing wallets to pay > to BIP114. Actually it should be completely transparent to them. This is correct. Your feedback will be incorporated. > For code complexity, the minimal BIP114 could be really simple, like > <30 lines of code? It looks complex now because it does much more > than simply hiding scripts in a hash. Is there a repo that contains the latest implementation of BIP 114, for comparison purposes? Kind regards, Mark Friedenbach ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST
On Mon, Sep 11, 2017 at 9:03 PM, Mark Friedenbach via bitcoin-dev wrote: > I believe you meant "unclean stack," and you are correct. This was > also pointed out last tuesday by a participant at the in-person > CoreDev meetup where the idea was presented. http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-07-merkleized-abstract-syntax-trees/ > > For code complexity, the minimal BIP114 could be really simple, like > > <30 lines of code? It looks complex now because it does much more > > than simply hiding scripts in a hash. > > Is there a repo that contains the latest implementation of BIP 114, > for comparison purposes? original bip114: https://github.com/bitcoin/bips/blob/775f26c02696e772dac4060aa092d35dedbc647c/bip-0114.mediawiki revised bip114: https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki https://github.com/jl2012/bitcoin/commits/vault from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014963.html - Bryan http://heybryan.org/ 1 512 203 0507 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Responsible disclosure of bugs
On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos 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. If you can't pick even a small group that's trustworthy (top five by market cap as a start [0]? or just major bitcoin wallets / exchanges / alt node implementations?), then it still seems better to (eventually) disclose publically than keep it unrevealed and let it be a potential advantage for attackers against people who haven't upgraded for other reasons? I find it hard to imagine bitcoin's still obscure enough that people aren't tracking git commit logs to use them as inspiration for attacks on bitcoin users and businesses; at best I would have thought it'd only be a few months of development time between a fix being proposed as a PR or committed to master and black hats having the ability to exploit it in users who are running older nodes. (Or for that matter, being able to be exploited by otherwise legitimate bitcoin businesses with an agenda to push, a strong financial motive behind that agenda, and a legal team that says they'll get away with it) > 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. Isn't that just an argument for putting more effort into backporting fixes/workarounds? (I don't see how you do that without essentially publically disclosing which patches have a security impact -- "oh, gosh, this patch gets a backport, I wonder if maybe it has security implications...") (In so far as bitcoin is a consensus system, there can sometimes be a positive network effect, where having other people upgrade can help your security, even if you don't upgrade; "herd immunity" if you will. That way a new release going out to other people helps keep you safe, even while you continue to maintain the same definition of money by not upgrading at all) If altcoin maintainers are inconvenienced by tracking bitcoin-core updates, that would be an argument for them to contribute back to their upstream to make their own job easier; either helping with backports, or perhaps contributing to patches like PR#8994 might help. All of those things seem like they'd help not just altcoins but bitcoin investors/traders too, so it's not even a trade-off between classes of bitcoin core users. And if in the end various altcoins aren't able to keep up with security fixes, that's probably valuable information to provide to the market... Cheers, aj [0] Roughly: BCash, Litecoin, Dash, BitConnect, ZCash, Dogecoin? I've no idea which of those might have trustworthy devs to work with, but surely at least a couple do? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Responsible disclosure of bugs
On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote: > I think it's relevant to treat different bug severity levels with different > response plans. That makes sense. For comparison, Monero defines a response process that has three levels and varies the response for each: ] a. HIGH: impacts network as a whole, has potential to break entire ]network, results in the loss of monero, or is on a scale of great ]catastrophe ] b. MEDIUM: impacts individual nodes, wallets, or must be carefully ]exploited ] c. LOW: is not easily exploitable -- https://github.com/monero-project/monero/blob/master/VULNERABILITY_RESPONSE_PROCESS.md Among other things, HIGH gets treated as an emergency, MEDIUM get fixed in a point release; LOW get deferred to the next regular release eg. Additionally, independently of the severity, Monero's doc says they'll either get their act together with a fix and report within 90 days, or otherwise the researcher that found the vulnerability has the right to publically disclose the issue themselves... I wouldn't say that's a perfect fit for bitcoin core (at a minimum, given the size of the ecosystem and how much care needs to go into releases, I think 90 days is probably too short), but it seems better than current practice... For comparison, if you're an altcoin developer or just bitcoin core user, and are trying to work out whether the software you're using is secure; if you do a quick google and end up at: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures you might conclude that as long as you're running version 0.11 or later, you're fine. That doesn't seem like an accurate conclusion for people to draw; but if you're not tracking every commit/PR, how do you do any better than that? Maybe transitioning from keeping things private indefinitely to having a public disclosure policy is tricky. Maybe it might work to build up to it, something like: * We'll start releasing info about security vulnerabilities fixed in 0.12.0 and earlier releases as of 2018-01-01 * Then we'll continue with 0.13.0 and earlier as of 2018-03-01 * Likewise for 0.14.0 as of 2018-05-01 * Thereafter we'll adopt a regular policy at http://... That or something like it at least gives people relying on older, potentially vulnerable versions a realistic chance to privately prepare and deploy any upgrades or fixes they've missed out on until now. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Responsible disclosure of bugs
On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev wrote: > All of those things seem like they'd help not just altcoins but bitcoin > investors/traders too, so it's not even a trade-off between classes of > bitcoin core users. And if in the end various altcoins aren't able to > keep up with security fixes, that's probably valuable information to > provide to the market... I have a reply to your point, but I want to clarify first that I am not trying to provide any sort of criticism of your character, and to any extent that my text is misinterpreted that way, that's entirely my fault here. Anyway, here goes. It's not enough to defend bitcoin and its users from active threats, there is a more general responsibility to defend all kinds of users and different software from many kinds of threats in whatever forms, even if folks are using stupid and insecure software that you personally don't maintain or contribute to or advocate for. Handling knowledge of a vulnerability is a delicate matter and you might be receiving knowledge with more serious direct or indirect impact than originally described. Besides the moral and ethical reasons to not unduly accelerate the exploitation of a vulnerability, there is also a reputational standpoint to consider, in that your position that your own (security) work is credible is actually harmed by showing negative care for other works by being first to publish either insecure software or knowledge of a vulnerability. And sometimes the opposite is true: by not disclosing knowledge of how a design is broken to someone inviting its review, you're showing negative care in that way too, such as by unintentionally encouraging the implementation of really bad ideas or entirely novel misunderstandings of what you once thought were clear concepts. So there is a difficult path to walk and especially in security not all may be as it seems; caution is highly recommended. Yes it would be good for "the market" to "get the signal" that altcoins are insecure, and that some altcoin vendors are literally and actively malicious entities, but I think everyone needs to take a step back here and very carefully consider the color of their hats, including those who advocate in the name of insecure downstream/forked software. The downside of the approach I've advocated for is that it requires knowledge, thinking and outsmarting the red teams; I am certainly aware of the allure of the approaches that involve absolutist statements like "anything weak [including bitcoin if it does have weaknesses] deserves to die and be actively exploited" but it's not something I am interested in espousing...nor do I think it would be healthy for this community to internalize that perspective. Instead we should continue to work on highly defensible software, and keep vigilant in regards to security. In "the [civilized] garden" I would expect there to be a general understanding that people collaborate and work together to build highly defensible evolving systems even if there exists knowledge of vulnerabilities. But we shouldn't be surprised when we don't go out of our way to contribute to alternative/parasitic systems... and we shouldn't be encouraging each other to actively bring about the eschaton by way of mishandling knowledge of vulnerabilities... I know these issues are difficult to get a handle on. Hopefully I've provided some useful perspective. - Bryan http://heybryan.org/ 1 512 203 0507 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev