Looking at the charts provided, out of 34 fixed bugs of "high importance" only 8 have been introduced in the last 5 years (i.e. after v3.0). So 75% of security fixes are for "legacy" bugs that have been introduced forever ago. The same ratio seems to hold true for the charts of "mid" and "low" importance (bit hard to tell with that resolution).
Over the same period, the kernel codebase grew from 8M LOC to 22M LOC. I'm not sure how to interpret this gap in security issues between the old "small" code vs the new massive code. Either kernel developers are a great deal more careful and the new code has a great deal fewer bugs, or we are about to get hit with a massive backlog of disclosures that bad guys are quietly piling up.
Let's say for simplicity's sake that _every_ bug needs exactly five years until it is found. This means that you will see zero bugs introduced in the last five years -- they haven't been found yet!
I believe most of that growth has been in the /drivers section of the kernel. While a driver can still root your kernel, the chance of one affecting you is much lower, unless it is one of the generic/common ones.
> The systems using a Linux kernel are right now running with security flaws. Those flaws are just not known to the developers yet, but they’re likely known to attackers.
I don't understand where he's deducing the second sentence from.
I guess it's the de-facto assumption with security vulnerabilities - if the vulnerability exists, there's a decent chance that someone knows about it and is using it. I'm not sure if there are any stats (retrospectively) about how "decent" that chance is.
1. No matter how many eyeballs you put on a bug, it does not become more shallow
2. Each bug lives on average for 5 years
This makes it probable that whomever puts enough resources on researching for bugs discovers them _before_ the developers find it out: 5 years is a very long time in terms of security assessments. It is reasonable to assume there are actors with enough such resources - these aren't necessarily neither large, e.g. states, nor malicious. They could be, for instance, independent researchers aiming to improve the kernel. That's what makes it probable these flaws are likely known to malicious 3rd parties.
It would be interesting, but a very tricky comparison to make as the Linux kernel and full OS' like Windows or OSX is not really a like-for-like comparison.
Windows and OSX cover large areas of functionality not really covered by the linux kernel (e.g. windowing systems) and the Linux kernel covers a wider range of devices than Windows or OSX so will have more a larger driver base.
Time is on the vertical axis (labeled with kernel versions that were released at that time instead of date). Horizontal axis is just an arbitrary bug number. It seems bugs are ordered first by severity and then by time they were fixed.
[+] [-] e1g|9 years ago|reply
Over the same period, the kernel codebase grew from 8M LOC to 22M LOC. I'm not sure how to interpret this gap in security issues between the old "small" code vs the new massive code. Either kernel developers are a great deal more careful and the new code has a great deal fewer bugs, or we are about to get hit with a massive backlog of disclosures that bad guys are quietly piling up.
[+] [-] hibbelig|9 years ago|reply
[+] [-] pixl97|9 years ago|reply
I believe most of that growth has been in the /drivers section of the kernel. While a driver can still root your kernel, the chance of one affecting you is much lower, unless it is one of the generic/common ones.
[+] [-] pif|9 years ago|reply
I don't understand where he's deducing the second sentence from.
[+] [-] danielbarla|9 years ago|reply
[+] [-] mfukar|9 years ago|reply
1. No matter how many eyeballs you put on a bug, it does not become more shallow
2. Each bug lives on average for 5 years
This makes it probable that whomever puts enough resources on researching for bugs discovers them _before_ the developers find it out: 5 years is a very long time in terms of security assessments. It is reasonable to assume there are actors with enough such resources - these aren't necessarily neither large, e.g. states, nor malicious. They could be, for instance, independent researchers aiming to improve the kernel. That's what makes it probable these flaws are likely known to malicious 3rd parties.
[+] [-] arganit|9 years ago|reply
[deleted]
[+] [-] kek918|9 years ago|reply
I doubt it, but it would be interesting to compare nontheless.
[+] [-] raesene6|9 years ago|reply
Windows and OSX cover large areas of functionality not really covered by the linux kernel (e.g. windowing systems) and the Linux kernel covers a wider range of devices than Windows or OSX so will have more a larger driver base.
[+] [-] viraptor|9 years ago|reply
[+] [-] barkbro|9 years ago|reply
I know this is probably meant to be read by people who know more about the subject than me, but adding some axis labels wouldn't hurt.
[+] [-] avian|9 years ago|reply
[+] [-] cheiVia0|9 years ago|reply
https://outflux.net/blog/archives/2016/10/20/cve-2016-5195/
[+] [-] walter_bishop|9 years ago|reply
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pro...