Linux trailed Windows in patching zero-days in 2012, report says

Linux trailed Windows in patching zero-days in 2012, report says

Summary: Zero-day flaws in the Linux kernel patched last year took on average more than two years to fix, twice as long as it took to fix those affecting current Windows OS, a report by security researchers has found.


Vulnerabilities in the Linux kernel fixed in 2012 went unpatched for more than two years on average, more than twice as long as it took to fix unpatched flaws in current Windows OSes, according security firm Trustwave.

Zero-day flaws — software vulnerabilities for which no patch is available — in the Linux kernel that were patched last year took an average of 857 days to be closed, Trustwave found. In comparison zero-day flaws in current Windows OSes patched last year were fixed in 375 days.

The gap in time between the patches being issued can partly be explained by the differing structures of open-source project communities and proprietary software vendors, according to John Yeo, director of TrustWave SpiderLabs for EMEA.

"In part it's related to the distributed nature of Linux development," he said.

"When you're talking about a vendor who's wholly and solely responsible for that particular product, it's somewhat easier for them to roll out a patch because it is very standardised.

"Whereas you might have different components or modules within the Linux kernel and many different people from an open source perspective who might be responsible for putting together a fix.

Vulnerabilities in common client and server software identified in the Trustwave report. Image: Trustwave

However the data shouldn't be interpreted as a claim that an OS built off the Linux kernel is necessarily less secure than using a Windows OS, as not every distro of Linux would necessarily be affected by every exploit, said Yeo.

"With the Linux kernel some of these CVEs (Common Vulnerabilities and Exposures) won't necessarily apply to one particular distribution," he said.

Matthias Kirschner, fellowship co-ordinator with the Free Software Foundation Europe, said there are many factors that can influence how long it can take to fix a zero day.

"Measuring zero day exploits is a bit difficult. How long did the developers already know about the exploit before it became public? That also influences how long it takes to fix it. If someone knows it before, eg because he implemented the exploit on purpose, it is easier to fix it — the solution might already be waiting for committing," he said.

"Free software can be developed in a very open collaborative development model, as well as it can be developed by one person in secret, without accepting any patches from others. That's why we recommend to differ between the software model, the development model, and the business model."

The zero-day vulnerabilities patched last year that were used to calculate the average time to patching are as follows:

Microsoft Windows 

  • CVE-2010-5082 detailed by independent researcher on Sept. 14, 2010 and not fixed until February 14, 2012. Affected Microsoft Windows Server 2008 SP2, R2, and R2 SP1.
  • CVE-2012-0181 fixes an issue alluded to on exploitdb site on Nov. 21, 2011, fixed July 10, 2012. Affected Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, Windows 7 Gold and SP1.

Linux kernel

  • CVE-2012-2100 is a correction to the fix detailed in CVE-2009-4307, which did not fully work on the common x86 platform. Trustwave considered this a zero-day due to availability of exploit information from the time of the original patch.
  • CVE-2012-2319 is a follow-up to CVE-2009-4020; issues in the HFS file system were detailed and patched on Dec. 3, 2009, but HFSPlus was left vulnerable until May 4, 2012.

The Trustwave report says the number of critical vulnerabilities, as determined by the Common Vulnerability Scoring System (CVSS) assessment of factors like potential impact and exploitability, identified in the Linux kernel was lower than in Windows last year, with nine in Linux compared to 34 in Windows. The overall seriousness of vulnerabilities was also lower in Linux than Windows, with Linux having an average CVSS score of 7.68 for its vulnerabilities, compared to 8.41 for Microsoft.

Topics: Security, Linux, Open Source, Windows


Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • So, the headline is misleading

    Correct, but once qualified by the author suggests the headline should be rewritten.
    • Many linux bugs are too big to fix

      ... due to poor coding quality, which is why they are left out there for so long
      • What evidence for that statement?

        And that is supported by the fact there were 9 critical vulnerabilities in Linux vs. 34 in Windows? Or the fact the average CVSS score was 7.68 for Linux vs. 8.41 for Microsoft? Or...
        • Microsoft Troll

          Once again, a Microsoft partner claims that Linux is less secure than Windows. What else would they say?

          Henrique Dourado
        • Not that data

          The data selected for this report was selected because of patch time, they are not the total number of vulnerabilities.

          If you want to play the number of vulnerabilities game you can look here (for the same year of 2012):

          Linux (the *kernel*) experienced 116 vulnerabilities in 2012.
          Windows 7 (the *entire* operating system) experienced 44 vulnerabilities in 2012.

          Yes, the Linux kernel *alone* had almost 3 times the vulnerabilities as that of the entire Windows 7. Consider that the Linux kernel does not contain the equivalent of DirectX, RDP, GUI Shell, font rendering, etc.

          What this report shows is that the Linux *kernel* is patched much slower than Windows.

          Sorry, another myth busted. I know it hurts. But sometimes truth hurts.
      • ROFL

        LOL... that's a good one. :D
        Technical John
      • Many linux bugs are too big to fix

        It is well-known fact that corporate drones produce extremely high-quality code. No so-called "opensource" developers can match them in quality, reliability and security.
        • "....extremely high-quality code"

        • nonesense.

          Most open source programmers ARE professional.

          And are also well known for producing high quality, secure, and reliable code.

          Not so true of many vendors... especially MS.
      • LBiege is an expert

        in coding, so we take his word. What about the Windows code quality? 12gb of bloat on Windows RT. Can we hear your expert opinion on that?
        The "report" in the article is an FUD. There so many blatant inconsistencies:
        1) Are comparing the whole Windows codebase with only Linux kernel? Or can you isolate the NT kernel part of it, no, you can't. (so a Windows part should receive a credit here)
        2) Comparing HFS filesystem .001% of Linux users use with a remote code execution of invariable Windows set up? ext4 is not pertinent to remote code execution either, it's a DoS problem. This is ridiculous.
        This is a pretty common tactics to compare vulns of very different severities and quite different prevalence.
        Is that simply incompetent or sponsored?
        I hope that, at least you get paid well by Microsoft and friends.
        • It is Linux that is bloated

          Just ask the creator himself.
        • It is Linux that is bloated

          The stupid comment system ate the link.

          here it is:

          Linus calls Linux 'bloated and huge':
      • LBiege Windoze fanbui extraordinaire says it's so... that must make it so...

        Let's all praise Windoze fanbui's for their extreme stupidity shall we...
    • The content isn't much better...

      "Zero-day flaws — software vulnerabilities for which no patch is available"

      No. Getting tired of this over use of buzz terms, especially when this leads to mis, or even incorrect information.

      Zero day refers to the vulnerability window; the time from the creation of a vulnerability until the time when it is patched. Zero day is most commonly used in the sense of a "zero day exploit" or "zero day attack" where by the maintainer of the software or the user becomes aware of a vulnerability after it has been exploited; exploiting an unknown vulnerability. They have a "zero days" to create a fix.

      If there has been no exploit then zero day is the day the vulnerability is discovered. If it is patched one year later without exploit, the vulnerability window was 365 days. If the vulnerability is discovered, then 90 days later it is exploited, it is a 90 day exploior 90 day attack.

      Zero day exploits are embracing for companies because an attacker found a vulnerability and exploited it before the company even noticed it. A 10,100 or even 1000 day exploit are equally embracing because the software has been exploited through a route known about to the company; people ask why they hadn't closed it.

      So does this refer to zero day exploits or vulnerability patching? This is very different; taking two years to close a zero day vulnerability is virtually negligence; it leaves your users wide open to known and present attacks for two years. Taking more than a decade to close a vulnerability that is unknown to either developer or attacker, although not ideal causes no real world problems so long as it does not become exploited.

      The other problem lies with the fact that this deals with numbers of vulnerabilities, not types of vulnerabilities; it's the old "there's more bacteria on your phone than a toilet seat" it may be true, but what bacteria are present is more important than their numbers.

      In response however I think this is what we would expect to see; one of the worlds top software companies patching vulnerabilities quicker than a community project.

      NB once again; zero day does not refer to a software breach; it refers to the time between the day the company becomes aware of the breach and the day the company became aware of the vulnerability that allowed the breach.
    • And risk losing clicks? Never!' gotta eat, y'know!
    • Hold on...

      The second Linux exploit is a very piss-poor example. The linux community dont have access to either code or documentation of Apple's filesystems HFS or HFS+, they must hack it and use the results of trial and error. That is the reason why it took a long time for that exploit to get fixed
    • Another misleading ZDNet headline..

      I agree @zaine_ridling... it's really apples-to-oranges comparing patching of Linux to patching of Windows. There is **ONE** Windows patch infrastructure, and it's built into the operating system, and richly supported by that **ONE** vendor.

      "Linux" on the other hand, exists in multiple distributions, and each of those distributions has its own patch management methodology (assuming one actually exists).

      Lately I've seen ZDNet headlines going for the "cheap shot" and I'm starting to wonder if this is really a news organization, or just another group of peeps-with-an-opinion-about-IT. :-//
      Lawrence Garvin
  • And in real world application

    It has meant absolutely nothing in terms of problems for me using Linux, and probably countless others on tablets and cellphones with Android, etc.
    D.J. 43
    •, ok.

      that's good that as a linux user you have never had any problems. I mean I can say the same thing too and I'm a windows user.
      • Never have any problems with windows

        I'm a Linux user and I never have any problems with windows either, that machine collects dust.