Debates
rage across the Internet about the comparative security of Microsoft Windows and Linux-based operating systems.
Many people have vested and biased interests in their positions on the matter. Misconceptions
born of incomplete knowledge and logical fallacies contribute to the confusion
and the heat of the debate. Advertising campaigns attempt to cast their
sponsors in the best possible light, and partisan studies use massaged
statistical data to produce apparently authoritative and objective, but
ultimately no less biased and suspicious, facts to bolster arguments.

Part
of the reason for seemingly endless debates without much certainty of
conclusions in sight is that many of the attempts to assess
security focuses on epiphenomena: they examine the surface features of
security without getting into much depth in analyzing the reasons for security
characteristics. Part of the reason for this is that, to major proprietary
software vendors, the workings of open source development are mysterious and
new. As a result, these corporate vendors of closed source software do not always
grasp what is happening behind the scenes with regard to security in the open
source world.

Another
part of the reason is that many of the people involved in the debates are end
users with only superficial understandings of what contributes to software
security. Even IT professionals often don’t understand the effects of software
architecture and development process on software security, because IT
professionals’ skills can exist anywhere in a wide range that often does not
include any real understanding of open source development and software
architecture, even when it does include a very in-depth understanding of
network and system security configuration.

Addressing
all the holes in the public knowledge of the underlying influences on software
security could be a matter of several thick volumes in print. A cursory
examination of a very limited selection from the broader subject area is
certainly possible, however, and that’s what this article aims to provide.

Ultimately,
the Linux vs. Windows security debate is a contest of examples. These examples
stand in place of the concepts that comprise a larger, more fundamental
question of what the security benefits and detriments are for the open source
and closed source development models. This is not only a technical matter. It
is also a matter of social factors, and when examined it begins to look
suspiciously like a matter for economists and game theorists. By far the more
misunderstood of the two approaches in most debates is the open source
development model. Let’s take a look at some of the facts of how open source
development relates to software security.

Security through obscurity

Several
security arguments directed at open source software are based on fallacious
reasoning. Many of the most irrational, and yet reasonable sounding arguments
against open source software center around the myth we call security through obscurity. One
commonly heard refrain is “You’ll see how secure it is when it’s as
popular as Microsoft!” Another is “Any old security cracker can see
the source code, so it’s not as secure!”

The security through obscurity fallacy
under girds the majority of arguments against the relative security of
Linux-based operating systems and the Mozilla Firefox browser. The truth of the
matter is that security through obscurity doesn’t really work to provide
functional security. It only provides the appearance of equivalent security
and, in fact, the open source development community relies on a principle of
security that is precisely the opposite. One might call it security through visibility, and it includes two sub-principles of
software security: security through transparency and security through
popularity.

Security through transparency

Open
source software development’s security is often questioned on the basis of the
availability of its source code to just anyone that wants it. The theory is
that by examining this source code, a would-be security cracker can find flaws
in the source code that constitute vulnerabilities, thus allowing exploits to be
more easily created for those vulnerabilities. There is some basis in fact
here, but not in the way people tend to assume.

The
truth is that analyzing source code by eye to find and catalog flaws that
create a vulnerability you can exploit is arduous and difficult work. If it was
as easy as suggested by the notion that open source software is more vulnerable
due to the availability of source code, almost nobody outside of Microsoft
would ever find vulnerability in Internet Explorer. It is, in fact, such a
difficult task for any nontrivial application that it is generally much easier
to find vulnerabilities through reverse engineering techniques. These
techniques involve poking at a working copy of the application, sending it
malformed input and otherwise mistreating it, then examining its stability and
output to determine how and when it behaves in a manner its programmers didn’t
intend.

There
may come a day when source code can be fed through another program to determine
where it contains flaws more easily than a program can be tested for
vulnerabilities through reverse engineering techniques, but by then the same
thing will be as easily accomplished with binary executable machine code files
without needing any access to the source code itself. After all, what is needed
for that sort of analysis isn’t information like what the programmer named a
given variable or method, but how the algorithms in targeted software are
constructed. Machine code is itself, functionally identical to source code
prior to being fed through a compiler, after all. The only difference is how
readable it is to a given programmer.

Statistically,
the facts do not support the assertion that open source software is inherently
more vulnerable. For instance, a report by code analysis company Coverity
found only 985 bugs in the 5.7 million lines of code in the Linux kernel. By
comparison, a study conducted by Carnegie Mellon University’s CyLab
indicated that a typical commercial, closed source program has between twenty
and thirty bugs per thousand lines of code. This bug rate would result in more
than 114,000 bugs in 5.7 million lines of code, over 114 times as many as found
in the Linux kernel.

An
important effect of software transparency in open source software development
is often referred to as Peer Review. This is the process whereby, because of
the public status of the source code and the fact that programmers working on
it do not uniformly serve the purposes of a single controlling entity such as a
corporate CEO, the people working on the source code serve to police each
others’ actions. The rare, but often vehement, argument that a malicious
programmer might add a “backdoor” to an otherwise legitimate piece of
open source software because the source code is open is clearly refuted by the
process of peer review, and by the often stringent and scrupulously applied
standards of quality for submitted code that gets accepted into an open source
software project’s code base. In fact, it could be pointed out that while the
source code of open source software is available for public review to find trojan horse capabilities written into a program,
proprietary software whose source code is not publicly available can and
sometimes does include intentionally added rootkit functionality that will
likely only be discovered by accident, after it has been widely circulated, as
happened with the infamous Sony rootkit of late 2005.

Security through popularity

The
popularity of the Microsoft Windows operating system on the desktop and
Internet Explorer as a Web browser is often cited as a reason for the rate of
vulnerability discovery and exploits. There is some truth to that. For a closed
source, proprietary operating system or Web browser, it is certainly true that
greater popularity would tend to bring greater attention from writers of
malicious code and other undesirables. Things change when introducing a whole
new development model in which popularity is a key factor, however.

With
open source software, there is a very low bar to entry for adopting a given
piece of software. Because open source software is not necessarily encumbered
by any price tag at all, in our increasingly networked world a new operating
system installer can be had for no more than the cost of a blank writable
compact disk and a few minutes for the download. Depending on your installation
method, even the price of the CD can be avoided.

The
ease of widespread adoption of open source software adds to the ease of
attracting new developers to an open source software project as well. As users
increase in number, so too do programmers with an interest in the project. The
developers from open source software are drawn from the pool of users, and in
addition to this open source software makes good use of casual interest amongst
programmers who do not have the time to devote to serious development team
involvement, but can easily spare a few minutes now and then to search for, and
fix, vulnerabilities and other bugs.

As a
result, the number of people looking at a popular piece of open source software
for vulnerabilities and other bugs to fix is disproportionately large when
compared with closed source software with a limited developer base. That number
increases as the number of users increases, as well. The people finding new
vulnerabilities for purposes of exploiting them are vastly outnumbered by those
finding new vulnerabilities for purposes of fixing them and, even when the people
finding the vulnerabilities do not themselves write the code to fix them, they
report their findings to people who will do so.

The
consequences of this state of affairs are clearly visible, as the fastest recorded Microsoft vulnerability patch distribution
after the vulnerability’s existence became public knowledge was the WMF library
patch earlier this year, with a turn-around time of “approximately nine to
10 days” according to Debby Fry Wilson, the director of the Microsoft
Security Response Center. Meanwhile, the Mozilla Foundation routinely produces,
tests, and releases patches for the Mozilla Firefox Web browser in less than a
week, and patch times for the Linux kernel are often measured in hours rather
than days.

This
is in large part due to the wide distribution of labor for patch testing: as
Debby Fry Wilson said when discussing the WMF patch’s quick release, what takes
a long time is testing–not patch development. It simply isn’t reasonable to
expect closed source software to keep up without the ability to test as widely,
and often to receive fixes from the testers themselves when testing runs into
problems, considering the open source development community’s access to a cast
of thousands of testers rather than dozens at best.

Proprietary software need not apply

Proprietary
software vendors such as Microsoft are beginning to investigate the feasibility
of harnessing some of the social forces at work in providing these benefits to
enhance the security of their proprietary software offerings. They’re
discovering that there are some distinct hurdles in their path, however, that
appear at this time to be insurmountable. Even the most liberally conceived
methods of achieving similar benefits, such as making source code publicly
viewable and offering new versions and patches for public testing in unlimited
distribution, fail to create the same positive environment for security through
visibility that is enjoyed by open source software.

The
reason for this is simple: the user base does not have the same investment in
the software itself. It is “someone else’s software”, and they cannot
be assured that the future development of the software will serve anyone’s
needs aside from those of the vendor. The potential loss of any invested time
and effort in the software’s development and improvement, due solely to the
whim of the vendor is a strong disincentive for involvement.

Visibility vs. Obscurity

The
open source development community relies on a distinctly different philosophy
of software security from that required by a closed-source, proprietary
development model. Obscurity can serve security concerns for proprietary
software vendors by keeping vulnerabilities out of the public eye long enough
for their programmers to develop patches, which safeguards market share by
creating a public image of security, even though this can often lead to periods
of widespread vulnerability without software users being aware they are at risk.
Open source software development provides benefits to visibility that more than
make up for any potential security losses incurred, and provides knowledge to
software users that they can use to protect themselves until a patch is
available. These benefits cannot ever be fully harnessed by proprietary
software.

Though
the question of visibility versus obscurity as a security characteristic is not
the only factor determining software security, it is an important one to
understand when examining the open source philosophy of software development,
and when analyzing the security characteristics resulting from these two very
different software development methodologies.