Kernel security, year to date [LWN.net]

Kernel security, year to date

Posted Sep 9, 2008 22:28 UTC (Tue) by bfields (subscriber, #19510)
In reply to: Kernel security, year to date by spender
Parent article: Kernel security, year to date

As for why the development model being a large reason for the problem, the easiest comparison (if we cover our eyes and assume the numerous vulnerabilities I've mentioned on this site and elsewhere for which there is no CVE don't exist, like the SELinux remote DoS), is to compare the numbers of CVEs for 2.4 against those for 2.6 for this year:

Yeah, unfortunately I think you'd have trouble convincing anyone that "number of CVE's" was a very useful statistic. (Unfortunate because it *would* be useful to be able to make those kinds of comparisons. I don't know what would be better. You could do audits of random samples of the code bases in question, but that sounds expensive. Statistics from the static analyzers and such might be better than nothing.)

(Log in to post comments)

Kernel security, year to date

Posted Sep 9, 2008 22:42 UTC (Tue) by spender (subscriber, #23067) [Link]

Well, unfortunately, it's the same metric being used to gauge the quality
of the Linux kernel's security in the very same article here that you're
commenting on. I completely agree that it's highly flawed (as I'd for
instance put the actual number of vulnerabilities fixed this year at around
80-100. For every vulnerability that gets public recognition, there is at
least one other than does not).

But at the same time, if we take into account the idea of silently fixed
vulnerabilities, there are *far* fewer bugfixes made to the 2.4 tree for
these to hide in compared to the 2.6 tree. It's not unreasonable at all I
think to say that with 40mb of code changes per stable release, it's not
exactly possible to maintain a secure codebase.

You could also look at how many of the vulnerabilities affected 2.6 only --
nearly all of the 2.4 vulnerabilities were present in 2.6 as well.
In 2.6, there have been many serious vulnerabilities recently but they
won't get much public attention because they only affect a small number of
recent kernels (the kernel developers fixing their recently introduced bugs
basically).

-Brad

Kernel security, year to date

Posted Sep 9, 2008 23:04 UTC (Tue) by nix (subscriber, #2304) [Link]

I'm not sure static analysis statistics are very useful, because bugs that
can be found by static analysis will have *been* found to some degree, and
thus preferentially fixed.

The interesting set is that which no static analysis tool can yet detect.
Unfortunately this is also the set that costs a bomb to locate.