
Security bug lifetime - avian
https://outflux.net/blog/archives/2016/10/18/security-bug-lifetime/
======
e1g
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.

~~~
pixl97
>the kernel codebase grew from 8M LOC to 22M LOC.

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.

~~~
e1g
I ran some stats[1], and turns out you're absolutely right: /drivers accounts
for 55% of growth in the codebase. Didn't know it was _that_ fat!

[1] [http://imgur.com/a/pdvFP](http://imgur.com/a/pdvFP)

~~~
woliveirajr
And arch takes a big slice too. Perhaps new supported functionalities for
specific processors ?

------
pif
> 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.

~~~
danielbarla
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.

~~~
0xFFC
Isn't this true for almost all projects? I am asking because they formed this
sentence in such way that means "this is only true for Linux kernel".

~~~
danielbarla
Definitely would be true for all projects. That said, perhaps with Linux's
omnipresence and role, it'd be very high on the target list (thus making it
more true here).

I didn't really read the sentence that way though - it felt more like a
clarification on why the number of vulnerabilities tend towards zero. Known
vulnerabilities are few in number, but this doesn't mean it's vulnerability
free.

~~~
uola
I wouldn't say "all projects". The statement is based on that they introduce
and remove vulnerabilities at a certain rate. A project that introduces less
vulnerabilities or finds them faster would be less likely to have privately
known vulnerabilities at any given time.

~~~
danielbarla
Good point. Though without perfect hindsight (or looking at any given time),
it's certainly possible that there are entire categories of privately known
vulnerabilities which are not even on the public radar. So it's quite possible
that the rate at which known vulnerabilities are fixed might be very
misleading. I guess they would offer a good base for the discussion
nevertheless.

~~~
uola
Sure, or if you find a way to find certain vulnerabilities quicker. A bug with
5 year life span that you can find in 1 month doesn't require you to find them
too frequently and more projects that fixes such bugs in 1 year will also be
vulnerable.

This is what I would assume someone like the NSA does. They would have
calculated a window of where it's most advantageous for them to find a bug and
will then spend the resources at that time. Both in terms of bug life time and
severity, but also user share.

------
kek918
Does Microsoft or Apple have a similiar infograph publicly available?

I doubt it, but it would be interesting to compare nontheless.

~~~
viraptor
You could probably pull that data out of the CVE reports. Just need to map
versions and patch releases to specific dates for calculations.

~~~
joosters
I don't think it would be possible; one of the interesting parts of the
article's graph is the 'creation time' of the vulnerability, but there's no
corresponding public data for Windows vulnerabilities.

~~~
viraptor
Yes, the granularity of the start date would be closer to 2y periods. (Major
windows versions affected)

------
barkbro
After reading it twice I'm still not sure what the horizontal axis represents.
Is it time in days?

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
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.

------
cheiVia0
Update for the latest security issue:

[https://outflux.net/blog/archives/2016/10/20/cve-2016-5195/](https://outflux.net/blog/archives/2016/10/20/cve-2016-5195/)

------
walter_bishop
Do these bugs still work on non x86 hardware?

[http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pro...](http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)

