Once again, my effort to explore common misperceptions (more recently exploring unpatched statistics) has brought out some of the common objections from those that don’t necessarily like the results. Very rarely do I get comments that can find a substantive problem with the analysis – instead the arguments tend to be detailed variations of “your comparison is not fair.” Now, nevermind that the “common perception” I am typically exploding was an even less fair comparison… ah, but let’s not digress.
First, let me say that these type of objections are not new. This past year, when I did year-to-date vulnerability comparisons – Windows vs Linux – Server – 1H06 and later Windows vs Linux – Workstation Comparison – Q3 2006 – similar objections arose. This is one reason that I keep a link to Apples, Oranges and Vulnerability Metrics on my home page, which is a decent introduction to the issues. Also, note that in the Q3 comparison, I did take pains to filter out “optional” components in the Linux distros and included only packages that had a comparable counterpart on Windows.
One comment I want to address came from Mike Howard’s blog, where he had given my recent analisys a shout-out. Here are Joe’s comments, along with my own comments back (in blue):
Jeff’s numbers are off.
The numbers are not off – they are as accurate as possible, given the assumptions and methodology that are laid out as part of the analysis. Joe’s further comments appear to try and justify this statement, so we continue.
Linux distributions are made up of third party software. Thus the number of vulnerabilities are not RedHat vulnerabilities, but vulnerabilities in third party software. RedHat didn’t *create* these vulnerabilities. However, since they ship the software, they have to provide updates.
Accurate statements in isolation, but I don’t see the relevance, nor do I see how they support the assertion that the numbers are “off”. Linux distributions are made up of many components originally developed and sometimes maintained by different groups. So? Red Hat has their own criteria for pulling together an Enterprise Product offering and then committing to their customers to support it for seven years. Does an end customer *care* who developed a RHEL component any more than they care which internal group, or set of external contractors, developed a Windows component? In my experience, they do not. More importantly, it doesn’t change the facts about disclosed and unpatched issues on the deployed OS in terms of contribution to risk.
Imagine a customer looking at a decision to standardize their desktop on a single platform for the next 5 years between Windows XP and RHEL4WS. Assume Enterprise support is important for that five year period, which is why they’re looking at RH and not Debian (if you need an explanation). If they’d like to get an accurate view of which product has more publicly disclosed, but unpatched issues, my original assertion was that the easily accessible data was misleading (thus the analysis and articles exploring this issue).
So comparing Windows with Linux doesn’t work. Microsoft does not issue patches for Adobe, Sun’s Java, Winzip, Quicktime, Firefox, Nero, Roxio, Cisco, etc.
I hold that it does work. However, I will agree that if a particular user wanted a more detailed comparison of his exact and full software stack, more work would be required. However, pointing out that more detailed work could be done does not invalidate a basic analysis with simpler assumptions concerning the vendor supplied and supported product.
The core of a linux distribution is the kernel, which is written by Linus. The kernel is useless without the userland and 3rd party software.
So to summarize:
RedHat is a collection of 3rd party software on top of the linux kernel, most of which is not written by RedHat.
Microsoft is a complete OS, all software shipped is written by Microsoft.
Apples and oranges.
The core part of these comments seem to hinge around whether a single vendor wrote the code. Again, I grant the accuracy of underlying statements (ie, kernel is useless without the 3rd-party components), but don’t see the relevance. I was not comparing vendors, but supported products.
No, they are not exactly apples to apples due to vendor choices. Honestly, a comparison of Ubuntu LTS and RHEL4WS also would not be apples to apples. However, does the fact that one vendor might by default deploy a bunch of software that many folks don’t need *add* to the security argument for that product or *detract* from it? One might argue that the inclusion of many of those “optional” components in a “default” installation is a vendor choice that affects customer security … in the same way that they inclusion of IIS in the default install of Windows 2000 affected customer security 5 years ago.
Read Apples, Oranges and Vulnerability Metrics for some more thoughts about comparisons.
If you really want to compare apples and apples, one should compare Microsoft and FreeBSD or OpenBSD, since these ship a complete base OS, like Microsoft does.
I find this comment to be the most humorous one of all. Really humorous, the more I think about it. Microsoft is a company, FreeBS and OpenBSD are OSes. But getting past that, Windows XP vs FreeBSD is no more an apples to apples comparison than Windows XP vs RHEL4WS or RHEL4WS versus FreeBSD. Each of them have different feature set and value/benefits that they promote to customers, and each have to accept both the positives and the negatives of the product choices made by the vendors. One would have to make a set of assumptions to do an analysis and readers would need to be aware of the context of the comparison in order to interpret it – exactly the same situation as here.
Moving on I’ll respond to a different from JNF:
Interesting, but misleading, while I don’t doubt your numbers in the least, I think its inaccurate to not point out that the majority of all of those bugs reported in windows affects everyone running windows, whereas a minority of those affecting RHEL affects everyone running RHEL.
Furthermore, you need to also ask how many patches has MS released for other peoples products? How many has RH released? How many of the bugs left unpatched in RHEL are for products created by RH or products that RH has a significant interest in (i.e. linux kernel [how many linux kernel developers work for RH?]). How many of those unpatched bugs in RHEL are being actively exploited? How many of those unpatched bugs are being actively exploited in MS products (i.e. msjet40.dll), How many of those products that RHEL has not patched are produced by third party vendors when there are no patches released by the vendor, so on and so forth.
That isn’t to say RH is not responsible for releasing patches, I’m just saying that this post is misleading because of the metrics it leaves out in its analysis- of course, all of these types of articles normally are (regardless of which side of the debate the author is on)
JNF – I think some of the discussion above helps set context here too, but primarily, I’d say that I think my results are less misleading than the easy to access data that was available prior to my analysis efforts. I have heard people specifically point out that Secunia shows RHEL has “zero unpatched issues” and then ask why Microsoft can’t achieve the same. That is not just misleading, but specifically inaccurate.
I do think that several of your other questions are interesting and might be interesting to pursue as separate research, but I don’t think the fact that I didn’t answer questions that I wasn’t trying to answer invalidates the results for the question I was focusing on – accuracy of unpatched data for Linux distros as represented by RHEL.
Best regards and thanks for taking the time to comment! ~Jeff
Kerberoasting, a well-known Active Directory (AD) attack vector, enables threat actors to steal credentials and navigate through devices and networks. Microsoft is sharing recommended actions administrators can take now to help prevent successful Kerberoasting cyberattacks.
Microsoft researchers found multiple vulnerabilities in OpenVPN that could lead to an attack chain allowing remote code execution and local privilege escalation. This attack chain could enable attackers to gain full control over targeted endpoints, potentially resulting in data breaches, system compromise, and unauthorized access to sensitive information.
Today, ahead of the Microsoft Build 2024 conference, we announced a new class of Windows computers, Copilot+ PC. Alongside this exciting new class of computers, we are introducing important security features and updates that make Windows 11 more secure for users and organizations, and give developers the tools to prioritize security.
Discover how to fortify your organization's cybersecurity defense with this practical guide on digital forensics from Microsoft's Incident Response team.
