The Security Industry: Where Objectivity Is a Lie

Open source in general, and Unix in particular, appears to be far buggier and less secure than is Microsoft’s code in general and Windows XP in particular.

You might not believe that, but any count of security vulnerabilities reported since about mid-2001 will lead you to the same conclusion. Mentions of Unix (including Linux, BSD and Solaris) outnumber mentions of Microsoft products by more than two to one across the major security databases.

There are several reasons for this. Superficially, it’s simply easier and safer to review open-source contributions than Microsoft’s work. You don’t have to read hex or use a decompiler, and nobody sues you for publishing your findings.

Less obviously, open-source code is easier to get than Windows code and there’s a lot more of it. Blastwave.org, for example, now offers more than one thousand freely downloadable packages for Solaris, all of which appear to have been studied by security industry organizations hunting security weaknesses in Unix and open source.

At bottom, however, the most important things going for the people who claim Unix and open source have more vulnerabilities than comparable Windows software is our willingness to accept the appearance of objectivity in place of the real thing.

Widely Available, Widely Used

Our naivet on this gets abused in two main ways. The first of these is a natural consequence of the fact that open-source code is widely available and thus widely used. Thus a minor problem with a memory allocation in a gnu utility can be, and usually is, listed as affecting essentially every known Unix product since Sun OS 3.0.

For example, the first candidate vulnerability listed in the downloadable ICAT database maintained by the Computer Security Division at the U.S. National Institute of Standards and Technology is said to affect:

BSDI, BSD/OS, 3.1 FreeBSD, FreeBSD, 1 FreeBSD, FreeBSD, 1.1 FreeBSD, FreeBSD, 1.1.5.1 FreeBSD, FreeBSD, 1.2 FreeBSD, FreeBSD, 2 FreeBSD, FreeBSD, 2.0.1 FreeBSD, FreeBSD, 2.0.5 FreeBSD, FreeBSD, 2.1.5 FreeBSD, FreeBSD, 2.1.6 FreeBSD, FreeBSD, 2.1.6.1 FreeBSD, FreeBSD, 2.1.7 FreeBSD, FreeBSD, 2.1.7.1 FreeBSD, FreeBSD, 2.2 FreeBSD, FreeBSD, 2.2.2 FreeBSD, FreeBSD, 2.2.3 FreeBSD, FreeBSD, 2.2.4 FreeBSD, FreeBSD, 2.2.5 FreeBSD, FreeBSD, 2.2.6 FreeBSD, FreeBSD, 2.2.8 FreeBSD, FreeBSD, 3.0 OpenBSD, OpenBSD, 2.4 OpenBSD, OpenBSD, 2.3

That’s 23 vulnerable Unix products for the price of one long-gone BSD vulnerability to syn flooding attacks of the kind now affecting Cisco’s BGP products.

Presenting the Facts

The second, and more important, problem is that a presentation based on giving “just the facts” can look objective while being highly deceptive. Consider, as an exaggerated illustration, this bit of pseudo-reporting:

Santa Fee – Jimmy Murphy, 6, got a scare Saturday afternoon when a 10 foot dust tornado roared across his little league lot. “It was horrible,” said a witness struggling visibly to remain claim. “Had it come closer, he might have had dust thrown in his face.”

Absurd, right? Well, consider this:

CAN-2003-0724

I made up the dust devil story, but the other implicit equation is from the ICAT metabase and perfectly illustrates the problem.

Both vulnerability reports are completely factual and devoid of any editorial or other opinion, but the implicit equality between one “high severity” Unix vulnerability and one high-severity Windows vulnerability is directly parallel to the comparison between little Jimmy’s fright and a disaster affecting millions in Florida.

Nobody Knows

Part of the truth here is that no one knows how many systems are affected by each of the vulnerabilities listed in this type of database. The compilers cannot, therefore, objectively justify a weighting system based on the expected number of victims and simply present “just the facts” unadorned by the information that the Unix vulnerability probably affected exactly nobody while the Windows bug opened millions of machines to a rather trivial exploit.

If you follow most of the Unix-related vulnerabilities to assess their actual incidence and viability, what you’ll usually find at the end of the trail is something like this:

So if malicious local user creates /tmp/something (which is written in the exploit binary), and then root user or root process executes archive.tgz, the local user can do something possibly.

Really.

It’s not that there aren’t Unix attacks that work. It’s that pretty much everything the security industry does misrepresents the actual balance between attacks on Microsoft’s products and attacks on Unix and open source.