Date: Mon, 13 Nov 2017 19:42:27 -0500 (EST) From: "David A. Wheeler" <dwheeler@...eeler.com> To: "oss-security" <oss-security@...ts.openwall.com> CC: "Vladis Dronov" <vdronov@...hat.com>, "oss-security" <oss-security@...ts.openwall.com> Subject: Re: CVE-2017-15102: Linux kernel: usb: NULL-deref due to a race condition in [legousbtower] driver On Mon, 13 Nov 2017 16:15:24 +0100, Greg KH <greg@...ah.com> wrote: > It's the arbitrarily nature here that I am curious about, it feels like > it should be "all or nothing", for CVEs to mean much here. Right now it > seems like it is just, "all that we care to track"? :) "All" would be awesome, though unlikely. But even if that's the eventual goal, "good starts" are still good starts. I think a very reasonable (and more practical) alternative is "enough CVEs to convince you to upgrade your kernel (or whatever) instead". In particular, if there are several CVEs assigned where the only reasonable mitigation is "you must upgrade your kernel", then you don't really *need* to assign more CVEs for purposes of telling people what they should do to mitigate their risks. If those CVEs apply to them, then they know they should upgrade & what the urgency is. It'd be *nice* to "have all vulnerabilities assigned CVEs", because that'd enable better statistical analysis of CVEs. In particular, developers would then have a better sense about the types of vulnerabilities that are really out there, in a specific product or in products in general. It'd be especially useful for seeing what mitigations work, and what doesn't. But I don't see that as a likely event in the near term. In any case, it is certainly not necessary for the main reason most people look at CVEs, where they simply need to answer the question, "What is the urgency to upgrade this component?". There are definitely problems in using CVEs to answer that question, because everyone *knows* the CVEs are incomplete & the assignment response time is less than ideal. And I *absolutely* agree that the current delays in upgrading kernels are a serious problem - Greg, I wish you EVERY piece of luck you can manage as you work on that!! However, today, "always upgrade the kernel when it costs $billions and we know the new version has vulnerabilities too and it's not clear how important it is to upgrade anyway" is not a compelling argument to most people. If you want people to upgrade *today* with any urgency, you need to give them a good reason, because currently the upgrade process is often painful. CVEs, while imperfect, give people a *reason* to go through the painful process of upgrading. If we can make software upgrades much easier in the future, then the reasons don't need to be as compelling, but that's not the case today. Thanks! --- David A. Wheeler
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ