Opening up kernel security bug handling

Posted Sep 12, 2013 9:33 UTC (Thu) by pabs (subscriber, #43278)
Parent article: Opening up kernel security bug handling

I wonder if using git notes in a particular format would be a better way to do things, you could tag which commit introduced a particular CVE and which fixed it as well as putting Fixes: CVE-XXXX-XXXX in the commit log.

to post comments

Opening up kernel security bug handling

Posted Sep 15, 2013 23:09 UTC (Sun) by error27 (subscriber, #8346) [Link] (4 responses)

The real problem is that most bugs do not get a CVE applied. There are three ways that CVEs are assigned.

1) If a bug is reported to security@kernel.org then someone from there is supposed to forward it to linux-distros and it gets a CVE. There was a gap where this wasn't happening but now it is.

2) Another way bugs get a CVE is if an outside security researcher finds it. Normally security researchers report the bug themselves to oss-security and get a CVE.

3) The last way that bugs get a CVE is if Kees Cook (Google), Petr Matousek (Redhat) or Prasad J Pandit (Redhat) see it going into -stable and flag it.

To double check my impressions I have looked at the first 20 kernel CVEs from this year. Here are the CVEs and the reporter.

CVE-2013-0160 vladz
CVE-2013-0268 Petr Matousek
CVE-2013-0309 Petr Matousek
CVE-2013-0310 Petr Matousek
CVE-2013-0343 George Kargiotakis
CVE-2013-0349 Prasad J Pandit
CVE-2013-0871 Google researchers
CVE-2013-0913 Kees Cook
CVE-2013-0914 Kees Cook
CVE-2013-1767 Jason A. Donenfeld
CVE-2013-1772 Petr Matousek
CVE-2013-1774 Prasad J Pandit
CVE-2013-1792 Prasad J Pandit
CVE-2013-1796 Petr Matousek
CVE-2013-1797 Petr Matousek
CVE-2013-1798 Petr Matousek
CVE-2013-1819 Prasad J Pandit
CVE-2013-1826 Mathias Krause
CVE-2013-1827 Mathias Krause
CVE-2013-1848 Petr Matousek

There aren't any from the first category in this list because the security@kernel.org to linux-distros liaison seems to have been AWOL. These are two private lists and at the time only one person was on both. Since last month the Redhat people and Kees have taken over that job.

There are 6 CVEs which were reported by security researchers.

The other 14 CVEs fall in under the last category where Kees, P J P or Petr spotted the bug.

What you don't see is ordinary kernel devs and maintainers requesting CVEs. This would probably have looked a little better if the liaison between the two private lists had been working better. But in general kernel devs just tag their patch for -stable and that's the end. We will see if that changes during the kernel summit.

Opening up kernel security bug handling

Posted Sep 15, 2013 23:35 UTC (Sun) by spender (guest, #23067) [Link] (1 responses)

> The other 14 CVEs fall in under the last category where Kees, P J P or Petr spotted the bug.

Or more often than not, spotted them in my changelogs or from me talking about them in public on IRC or Twitter ;) (sometimes for weeks, as in the case of the MSR vuln) Also explains much of the missing 4) Patch not marked for -stable but somehow gets a CVE anyway

-Brad

Opening up kernel security bug handling

Posted Sep 16, 2013 7:00 UTC (Mon) by error27 (subscriber, #8346) [Link]

True. Also Redhat customers sometimes report security bugs and Redhat developers sometimes flag a bug as security related.

Opening up kernel security bug handling

Posted Sep 17, 2013 2:37 UTC (Tue) by kurtseifried (guest, #57307) [Link] (1 responses)

It's not like we've made it hard to get CVE's, I've been at Red Hat for 2 years now (as of last week), took over CVE assignments early on.

http://people.redhat.com/kseifrie/CVE-OpenSource-Request-...

the afore mentioned methods will work to get CVEs, you can also request them privately (but for linux kernel stuff especially the distros@ list is much preferred as this also ensures all the large Linux vendors get notified.

Opening up kernel security bug handling

Posted Sep 17, 2013 12:27 UTC (Tue) by error27 (subscriber, #8346) [Link]

It's not clear why more kernel developers don't file for CVEs.

One reason is maybe that people prefer silent fixes.
http://www.pcpro.co.uk/news/security/213213/torvalds-rage...
Personally, I feel that these days the danger is not about script kiddies so we should just spell out the danger.

One thing is that maintainers already have enough things to do. It's ridiculous to imagine that Greg K-H is going to do all the security analysis by himself. Anyone can file for CVEs if the want to. Greg thinks that distros already do that job and are able to understand which -stable patches have security impacts.
https://lwn.net/Articles/539282/

As a kernel contributor, I decided I would let the individual maintainers decide for themselves how they want to handle security bugs. I always spell out the implications. So far no maintainers have ever filed for a CVE but occasionally P J P will tag one of my patches.
http://www.spinics.net/lists/stable/msg16881.html
I pretty much agree with Greg on that. One byte of stack info seems like a minor thing.

A lot of the time, I don't know the security implications myself. Which parts of the code are root only? Is an off-by-one check just a sanity check and can't ever be triggered? If we read one space beyond the end of the array is that a problem?