Security in Operation (2/4): When an Issue Affects Multiple Products

  • Article

Security Management

By Jeffrey R. Jones
Director, Microsoft Security Business and Technology Unit

See other Security Management columns.

As part of my work for Microsoft, I have spent a lot of time analyzing OS security, customer feedback, metrics for progress, and where those three things intersect. One thing I’ve discovered is that there is quite a large gap between the theoretical idea of security and the practical security concerns of customers. This article is the second of a four-part series in which I’ll be examining those customer concerns and raising questions to think about with respect to using either a Microsoft Windows–based or a Linux-based operating system.

It is not uncommon that any given vulnerability found will affect multiple products or versions of a product. Although that fact is obvious upon reflection, I want to dig a little deeper to expose how Microsoft and the Linux/Open Source community handle the issue and to examine some of the practical implications for customers.

Mitre CVE List

People who start to learn about software vulnerabilities quickly learn that the Mitre Common Vulnerabilities and Exposures (CVE) ID (read about it here) is the standard identifier used. One can take an example identifier, CAN-2004-1234 and look it up on Mitre by preceding the ID with “https://cve.mitre.org/cgi-bin/cvename.cgi?name=” to create a URL (for example, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1234).

Looking at the “1234” example I picked, we see that there are references to a Red Hat Security Advisory, one to BitKeeper, a pointer to Bugzilla, Securityfocus, and ISS. The Securityfocus reference page indicates that all Linux kernels prior to 2.4.26 are affected and lists more than 100 versions of Linux distributions that incorporate those kernel versions and are negatively affected.

Security Risk Implications of Multiple Vulnerable Versions

Switching back to using Microsoft as an example for a moment, let’s look at Security Bulletin MS04-018. This bulletin advises customers of a header verification problem that affects Outlook Express (OE) and could allow an attacker to make OE crash. The bulletin indicates that six currently supported versions of OE are affected when running on various versions of the Windows operating system back to Windows 98 and Windows NT.

What if Microsoft first released a fix for only the version of OE running on Windows XP, with the intent to release fixes for the other versions over time? How would this affect security risk for the other versions? There are two situations:

  • If the issue is already publicly known, the release of the fix highlights the vulnerability and makes it better known to a broader set of people.

  • If the issue is not already public, the release makes it public and makes it better known to a broader set of people.

In both situations, security risk would increase for users of versions for which no fix is available because more potential attackers have been made aware of a hole to attack, while some customers still have no fix from vendors. This leads to the conclusion that to minimize security risk for customers across all versions of a product, a vendor should have a policy of releasing a fix for all versions at the same time.

Issues Affecting Multiple Microsoft Products

When the Microsoft Security Response Team becomes aware of a security vulnerability, either privately or publicly, Microsoft has a policy of fixing all supported versions in all languages at the same time. This policy is possible because Microsoft provides support and maintenance for all of the affected versions. An article I wrote last year provides a deeper examination of how Microsoft handles reported issues.

The one main cost of the process of fixing all supported versions at the same time is that any testing issue found in one of the fixes will cause a delayed release of all fixes. As a security practitioner, I view this cost as well worth the tradeoff of reducing security risk across the users of the various versions of the product.

Issues Affecting Multiple Open Source/Linux Products

Both a strength and weakness of open source software is that anybody can create a variant and begin supporting it. With respect to the topic of this article though, the open source development model presents some extra challenges for open source products in terms of security risk.

Recalling our “1234” example that affected over 100 distributions of Linux: Is it possible to coordinate the release of a single fix for all versions at the same time? In theory, absolutely! In practice, it is a bit more difficult. There are at least two parts of the open source model that present challenges in this area:

  • Issues fixed first by one of multiple Linux distributions (for example, Gentoo, Debian, or Red Hat).

  • Issues found and fixed by component (for example, Mozilla or gcc) development teams

The Multiple Distribution Problem

The distrowatch Web site says:

A Linux distribution is like a religion. If you've ever tried to suggest to another person that his or her choice of a distro might not be the best, then you know what I mean. Even if you haven't, you have probably come across a "distribution opinion war" on one of the mailing lists or public forums. But that's OK. We should be passionate about things we love, even if it's just a mass of programming code. What follows are facts and figures about Linux distributions. Personal opinions may vary, but facts are a lot more difficult to dispute...

The site goes on to say that:

Currently, there are a total of 386 Linux distributions and 9 BSD distributions in the database. Of these distributions, 50 have been officially discontinued, or the distribution's Web site (or product information) simply disappeared or became inactive (that is, they haven't released a new version in more than two years and their Web sites don't give any indication of work in progress).

Let’s look at our 1234 example again and see what happened.

  • On April 9, 2004, Kirill Korotaev sent a message to the linux-kernel mailing list, to which Chris Wright of OSDL responded, saying yes and the fix is already in the 2.6 kernel.

  • Red Hat released a fix with Security Advisory RHSA-2004:689 on December 23, 2004. Red Hat acknowledged Kirill Korotaev as the finder of the issue.

  • According to both ISS and Securityfocus, December 23 was the first public disclosure of issue CAN-2004-1234 to anyone outside of linux-kernel subscribers.

  • Avaya, which used Red Hat in some of its products, issued advisory ASA-2005-006 on January 12, 2005, advising of a fix.

  • For the Fedora distributions, Fedora Core released FLSA:2336 on February 24, 2005, roughly two months after the Red Hat security advisory.

  • I can’t find advisories from any other distributions at this point. For example, although SuSE Enterprise Linux 8 is listed as affected, Novell has yet to release a security advisory that mentions CAN-2004-1234.

This example emphasizes that when one distribution advises of a security fix, other distributions may face an elevated security risk until they release a fix themselves.

Note that an upside for users of one of these unpatched and unadvised distributions is that they can get a kernel fix directly and apply it -- even if their vendor has not notified them of the security issue or issued a fix. There could be implications to their support agreement, but they do have the option.

The Patched Component Problem

Distributions of Linux are created by taking a snapshot of lots of components at some point in time and, with some distribution development glue, releasing the set as an OS version. Examples of this would be Red Hat Enterprise Linux AS v2.1, SuSE Linux Enterprise 8, and Ubuntu 4.10. Let’s take a look at SUSE Security Announcement - kernel (SUSE-SA:2004:037) that addressed CAN-2004-0816 on SuSE Linux Enterprise Server 9 (SLES9) on October 20, 2004. The advisory says:

An integer underflow problem in the iptables firewall logging rules can allow a remote attacker to crash the machine by using a handcrafted IP packet. This attack is only possible with firewalling enabled.

We would like to thank Richard Hart for reporting the problem.

This problem has already been fixed in the 2.6.8 upstream Linux kernel, this update contains a backport of the fix.

The use of the word “backport” is indicative of the new component problem for distributions. Information on Securityfocus shows that any distribution utilizing a 2.6 version of the kernel prior to 2.6.8 is affected. Their kernel team has addressed the issue -- the fix is to upgrade the kernel to 2.6.8 or later.

The problem is that some distributions took a snapshot of the kernel prior to 2.6.8, and that version is what their customers use as the supported version. SuSE SLES9 and a couple of versions of MandrakeSoft fall into this category. So the vendors must backport the fix and release it as a patch for the version of the kernel they have committed to support for their customers, as SuSE did. Note that the multiple distribution problem kicks in here too, as MandrakeSoft users did not get a patch until January 25, 2005, with MDKSA-2005:022.

Taking a second example from the other end, looking at issues that affected v1.3 on the Apache Web site, we find CAN-2004-0174. The first reference for the CVE is to an announcement on bugtraq on March 19, 2004, that Apache HTTP Server 2.0.49 has released. The announcement notes that 2.0.49 fixes CAN-2004-0174 since 2.0.48. Subsequent checking shows that various distributions provided security advisories for their version of Apache to their customers as follows:

  • March 30, 2004, Trustix

  • May 3, 2004, Apple

  • May 12, 2004, OpenPKG and Slackware

  • May 17, 2004, MandrakeSoft

  • May 26, 2004, Gentoo

  • July 23, 2004, Red Hat

One final example comes from Debian Security Advisory DSA-639, which explicitly notes the following for 10 vulnerabilities:

Andrew V. Samoilov has noticed that several bugfixes which were applied to the source by upstream developers of mc, the midnight commander, a file browser and manager, were not backported to the current version of mc that Debian ships in their stable release.

So, although the open source model allows each of these vendors to tweak their own version of a component, and potentially commit support for customers beyond what the component team will do, there are some practical security maintenance issues that end up affecting customer security risk.

Conclusions

When comparing vendors or products, all too often the values and benefits are oversimplified into a set of comparison check boxes. For anybody offering a product to companies, along with a support and life-cycle commitment, providing security fixes is an entry-level requirement.

Beyond the basics, though, there are practical implications to security risk that arise from both the vendor policies and their ability to support multiple versions in a timely manner. When the open source model is considered in this light, the multiple vendors and multiple distributions have a clear dependency and impact on one another that present real challenges to managing security risk.

As with any comparative security discussion like this, I advise you to check up on this topic yourself and draw your own conclusions. I’ve provided several references for you to follow and listed some questions you might want to discuss with your vendor, though I am sure you will add to the list.

Join me next month for the next article in this series about practical security issues to consider for operational environments. I will explore some of the practical security considerations related to “fixes made available in hours.”

Best Regards,
Jeffrey R. Jones
Senior Director, Microsoft Security Business and Technology Unit