The secrets of open source security

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 analysing 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 analysing 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.