6 ms·

Security bug lifetime

84 points by avian 10y ago

pif 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      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.
      - 0xFFC 10y ago
        Thank you
      - uola 10y ago
        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 10y ago
        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 10y ago
        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.
        eeZah7Ux 10y ago
        > it's certainly possible that there are entire categories of privately known vulnerabilities which are not even on the public radar This happened many times for both closed on open source projects. Not surprisingly, given how much is paid for a 0-day.
    - noselasd 10y ago
      I didn't interpret it that way at all. It's an article about flaws in the linux kernel, so it's quite natural the sentence was formed the way it was - without meaning to imply that it is true only for Linux.
- arganit 10y ago
  ever heard of Ac1db1tch3z,spender,pipacs,GOBBLES or PHC ?
- mfukar 10y ago
  The bug lifetime analysis shows two things: 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.
kek918 10y ago
Does Microsoft or Apple have a similiar infograph publicly available? I doubt it, but it would be interesting to compare nontheless.
- viraptor 10y ago
  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 10y ago
    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 10y ago
      Yes, the granularity of the start date would be closer to 2y periods. (Major windows versions affected)
  - hannob 10y ago
    You could, and you'd add your name to the long list of people creating bad statistics about CVEs. See this talk: https://www.youtube.com/watch?v=3Sx0uJGRQ4s https://www.youtube.com/watch?v=3Sx0uJGRQ4s
- raesene6 10y ago
  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.
  - eeZah7Ux 10y ago
e1g 10y ago
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 10y ago
  >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 10y ago
    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
    - deleted 10y ago
      [deleted]
    - woliveirajr 10y ago
      And arch takes a big slice too. Perhaps new supported functionalities for specific processors ?
- hibbelig 10y ago
  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!
barkbro 10y ago
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 10y ago
  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.
walter_bishop 10y ago
Do these bugs still work on non x86 hardware? http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pro...
cheiVia0 10y ago
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/

84 points by avian 10y ago

pif 10y ago

> 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 10y ago
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 10y ago
  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 10y ago
    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.
    - 0xFFC 10y ago
      Thank you
    - uola 10y ago
      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 10y ago
        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 10y ago
        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.
        eeZah7Ux 10y ago
        > it's certainly possible that there are entire categories of privately known vulnerabilities which are not even on the public radar This happened many times for both closed on open source projects. Not surprisingly, given how much is paid for a 0-day.
  - noselasd 10y ago
    I didn't interpret it that way at all. It's an article about flaws in the linux kernel, so it's quite natural the sentence was formed the way it was - without meaning to imply that it is true only for Linux.
arganit 10y ago
ever heard of Ac1db1tch3z,spender,pipacs,GOBBLES or PHC ?
mfukar 10y ago
The bug lifetime analysis shows two things: 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.

kek918 10y ago

Does Microsoft or Apple have a similiar infograph publicly available? I doubt it, but it would be interesting to compare nontheless.

viraptor 10y ago
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 10y ago
  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 10y ago
    Yes, the granularity of the start date would be closer to 2y periods. (Major windows versions affected)
- hannob 10y ago
  You could, and you'd add your name to the long list of people creating bad statistics about CVEs. See this talk: https://www.youtube.com/watch?v=3Sx0uJGRQ4s https://www.youtube.com/watch?v=3Sx0uJGRQ4s
raesene6 10y ago
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.
- eeZah7Ux 10y ago

e1g 10y ago

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 10y ago
>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 10y ago
  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
  - deleted 10y ago
    [deleted]
  - woliveirajr 10y ago
    And arch takes a big slice too. Perhaps new supported functionalities for specific processors ?
hibbelig 10y ago
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!

barkbro 10y ago

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 10y ago
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.

walter_bishop 10y ago

Do these bugs still work on non x86 hardware? http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pro...

cheiVia0 10y ago

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/