[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 Nov 2017 14:29:15 -0500
From: Stiepan <stie@....swiss>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: CVE-2017-15102: Linux kernel: usb: NULL-deref due to a race condition in [legousbtower] driver
> -------- Original Message --------
> Subject: Re: [oss-security] CVE-2017-15102: Linux kernel: usb: NULL-deref due to a race condition in [legousbtower] driver
> Local Time: November 9, 2017 5:09 PM
> UTC Time: November 9, 2017 5:09 PM
> From: dwheeler@...eeler.com
> To: oss-security <oss-security@...ts.openwall.com>
>
>>> On Tue, 2017-11-07 at 21:22 +0100, Greg KH wrote:
>>>
>>>> I hate to ask, but why are you getting CVEs for bugs fixed over a
>>>> year ago, and are already in all stable kernel releases a year ago? Why
>>>> does it matter?...
>>>>
>>>> On Tue, Nov 07, 2017 at 08:30:05PM +0000, Maier, Kurt H wrote:
>>
>>> Kernel maintainers' policy is clear, and nobody is asking for that to
>>> change, but please don't sandbag the process of keeping track of
>>> vulnerabilities. The fraction of "products" (regardless of vendor)
>>> that run linux and never get updates approaches unity. Being able to
>>> precisely catalog which linux releases suffer from which
>>> vulnerabilities is useful to many.
>>>
>>> On Wed, 8 Nov 2017 10:15:17 +0100, Greg KH greg@...ah.com wrote:
>>> Well, I'm working on fixing the "devices do not get updates" issue
>>> through other means, so don't just give up on that one just yet :)
>>>
>>> I applaud your work! I think getting CVE assignments may help, as I explain below.
>>>
>>> As for the "keep track of vulnerabilities", is that what is really
>>> happening here? Why pick a random bug fix from over a year ago for a
>>> CVE vs. the 100 other bugfixes in the past few weeks/months?
>>
>> I'm really curious as to what triggered this specific CVE request that
>> somehow misses the hundreds/thousands of other fixes that land in newer
>> kernel releases?
>>
>> Manufacturers & recipients often won't update unless there's a reason to update.
>> Documenting a number of specific CVEs in older kernel versions
>> provides clear documented reasons that an update needs to occur,
>> instead of a vague "you should upgrade" claim.
>>
>> Perhaps most importantly, once a vulnerability has a CVE id,
>> some laws and regulations can come into play. Manufacturers
>> will (correctly) argue that no one can track all the mailing lists, but if a
>> vulnerability has a CVE id, it's generally agreed that the
>> vulnerability is a publicly known vulnerability.
>> In the US, there has been recent proposed legislation that requires
>> that "Internet of Things" devices sold to the federal government cannot have
>> "known security vulnerabilities" ("Internet of Things Cybersecurity Improvement
>> Act of 2017" proposed by Senators Mark Warner (R-Va.) and Cory Gardner (D-Colo.)).
>> I suspect many other countries have or will pass similiar laws,
>> or will interpret their existing laws this way.
>> It's easy to argue that known security vulnerabilities are known flaws
>> that should be remediated by the manufacturer (at no cost to the consumer).
>>
>> I agree that many vulnerabilities don't have CVE ids.
>> You don't need to identify all vulnerabilities in old kernels... just enough to make
>> it easier to update the kernel than try to back-patch everything.
>> If manufacturers have to fix the CVEs to sell products, or to avoid massive returns,
>> that creates an economic reason for manufacturers to
>> begin responsibly maintain their products.
>>
>> There's no guarantee that this sequence of events will happen, but it's worth trying.
>>
>> --- David A. Wheeler
I would like to add that starting in May, 2018, companies will have the huge incentive of the European GDPR, with fines going up to 4% annual turnover of the company or group in case of a breach involving EU citizen's data. Here in Switzerland we will have a "light" version with fines capped to 250k CHF. But we're only about 8M (although, including many people and companies in a position to hire lawyers). This makes some incentives already. Now back to the specific question of CVE IDs, it's a tough one, knowing that not everyone might agree on that "single root of trust"... But I would say here, something is way better than nothing!
About the "fraction nearing unity", Linux-specific problem: this is why we are evaluating all possible open-source kernels for a secure "CEuniX"*, in collaboration with two EU-based organizations and a Canadian dev. First results should be published before the May 2018 deadline, giving people an early direction to follow in their journey to compliance. Actually this is a turning point - where law exceeds tech - instead of the reverse, which usually happens. Or perhaps better said, the rule of law will soon apply to the digital world, "fully". (Europe is far from being the only one, as was hinted by David; this is an international trend, where cultural differences will come into play and can have a crucial role in shaping how those laws are made and implemented in the real world, ultimately affecting our lives.)
Stiepan A. Kovac
*please e-mail me for details about the project, which is an H2020 candidate, meaning it is likely to get funding from the European Commission
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
