Security Innovation has joined the elite group of Microsoft-funded
researchers who somehow manage to reach pro-Microsoft conclusions. This
company's latest output is a report
on the relative security of Linux and Windows web servers [PDF]
states that Windows is more secure, in this role, than Red Hat Enterprise
Linux. The group did its work
by looking at all of the vulnerabilities fixed by each vendor in 2004 (as
designated by CVE numbers), and determining how much time passed between
the initial disclosure of the problem and the resulting fix. Windows
showed fewer vulnerabilities, and significantly fewer "days of risk" when
disclosed problems lacked a patch.
Those who want to poke holes in this study should be able to find ample
opportunity. Microsoft vulnerabilities are less likely to be disclosed
prior to patching, to the point that the median "days of risk" for Windows
was zero. The report cautions against writing off "low risk"
vulnerabilities, but, somehow, Microsoft simply does not have any
"low risk" problems. Either that, or Microsoft doesn't bother to fix them,
resulting in many undisclosed "days of risk." Red Hat will also have
gotten burned by this libpng
vulnerability, which, by mistake, remained unfixed for two years.
That's a lot of days of risk, even though no known exploits of this
vulnerability took place.
Let's focus on one specific claim, however:
There were thirty one [RHEL] vulnerabilities fixed in 2004 that had
more than 90 days of risk, and of these, seven were designated by
ICAT as high severity... Eleven of these vulnerabilities were in
the operating system kernel.
The report does not list the actual vulnerabilities it looked at, so we'll
have to try to reproduce that work ourselves. Here's the kernel
vulnerabilities fixed by Red Hat in 2004:
The attentive reader may have noticed that this is a rather long list of
vulnerabilities. Summed up, it amounts to a total of 2943 days of risk - a
substantial portion of the 12,415 days of risk cited in the report.
One immediate conclusion is that, in many cases, we are talking about "days
of very low risk." The strncpy() information leak was worth
fixing, but few people were likely to be overly worried during the 305 days
it took for Red Hat to issue updates with that fix. The same is true of
the TTY character count leak (737 days of risk). Both ia-64 users could
probably live with the floating point leak on that platform (209 days of
risk). In other words, many of the vulnerabilities which had a big
contribution to the total number of days of risk were of little concern.
On the other hand, Red Hat was slow in fixing some important
problems. The kmod denial of service and ELF vulnerabilities took months
to fix - and they were clearly (locally) exploitable problems. Red Hat is,
at times, leaving its paying customers with known security problems for
longer than it should.
Interestingly, many of these problems were fixed more quickly in other
distributions - including Fedora Core. Red Hat's stability
goals for its Enterprise Linux line could be an issue here. The need for
more stress and regression testing of kernel updates, combined with a clear
wish to minimize the number of disruptive kernel updates (many updates
fixed several vulnerabilities), is causing those updates to be delayed.
Thus, one might draw the ironic conclusion that, if you want the fastest
security updates, you're better off not paying for them.
There are some more predictable conclusions as well. One is that reports
like the one from Security Innovation still do not mean a whole lot. There
are too many variables; it is hard to get a handle on which system is truly
more secure, and it is too easy to tilt the data in one direction or the
other. Of course, one could look at the number and cost of actual
security incidents, but these Microsoft-funded surveys tend not to do
that. The final, predictable conclusion is this: regardless of how Linux
performs relative to other systems, we are not doing nearly well enough.
As long as we are producing such long lists of bugs (for a single system
component), our claims to security will only hold so much water.
to post comments)