The Myth of Open Source Security Revisited v2.0

Dare Obasanjo contributed this followup to an article entitled The Myth of Open Source Security Revisited that appeared on the website kuro5hin. He writes: "The original article tackled the common misconception amongst users of Open Source Software(OSS) that OSS is a panacea when it comes to creating secure software. The article presented anecdotal evidence taken from an article written by John Viega, the original author of GNU Mailman, to illustrate its point. This article follows up the anecdotal evidence presented in the original paper by providing an analysis of similar software applications, their development methodology and the frequency of the discovery of security vulnerabilities." Read on below for his detailed analysis, especially relevant with the currency of security initiatives in the worlds of both open- and closed-source software.

The Myth of Open Source Security Revisited v2.0 The purpose of this article is to expose the fallacy of the belief in the "inherent security" of Open Source software and instead point to a truer means of ensuring the quality of the security of a piece software is high.

Apples, Oranges, Penguins and Daemons

When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.

A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.

There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.

Security Vulnerability Face-Off

Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.

Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.

Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).

The Road To Secure Software

Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.

1. Formal Methods: One can use formal proofs based on mathematical methods and rigor to verify the correctness of software algorithms. Tools for specifying software using formal techniques exist such as VDM and Z. Z (pronounced 'zed') is a formal specification notation based on set theory and first order predicate logic. VDM stands for "The Vienna Development Method" which consists of a specification language called VDM-SL, rules for data and operation refinement which allow one to establish links between abstract requirements specifications and detailed design specifications down to the level of code, and a proof theory in which rigorous arguments can be conducted about the properties of specified systems and the correctness of design decisions.The previous descriptions were taken from the Z FAQ and the VDM FAQ respectively. A comparison of both specification languages is available in the paper, Understanding the differences between VDM and Z by I.J. Hayes et al.
   
   
2. Code Audits: Reviews of source code by developers other than the author of the code are good ways to catch errors that may have been overlooked by the original developer. Source code audits can vary from informal reviews with little structure to formal code inspections or walkthroughs. Informal reviews typically involve the developer sending the reviewers source code or descriptions of the software for feedback on any bugs or design issues. A walkthrough involves the detailed examination of the source code of the software in question by one or more reviewers. An inspection is a formal process where a detailed examination of the source code is directed by reviewers who act in certain roles. A code inspection is directed by a "moderator", the source code is read by a "reader" and issues are documented by a "scribe".
   
   
3. Testing: The purpose of testing is to find failures. Unfortunately, no known software testing method can discover all possible failures that may occur in a faulty application and metrics to establish such details have not been forthcoming. Thus a correlation between the quality of a software application and the amount of testing it has endured is practically non-existent.
   
   There are various categories of tests including unit, component, system, integration, regression, black-box, and white-box tests. There is some overlap in the aforementioned mentioned testing categories.
   
   Unit testing involves testing small pieces of functionality of the application such as methods, functions or subroutines. In unit testing it is usual for other components that the software unit interacts with to be replaced with stubs or dummy methods. Component tests are similar to unit tests with the exception that dummmy and stub methods are replaced with the actual working versions. Integration testing involves testing related components that communicate with each other while system tests involve testing the entire system after it has been built. System testing is necessary even if extensive unit or component testing has occured because it is possible for seperate subroutines to work individually but fail when invoked sequentialy due to side effects or some error in programmer logic. Regression testing involves the process of ensuring that modifications to a software module, component or system have not introduced errors into the software. A lack of sufficient regression testing is one of the reasons why certain software patches break components that worked prior to installation of the patch.
   
   Black-box testing also called functional testing or specification testing test the behavior of the component or system without requiring knowledge of the internal structure of the software. Black-box testing is typically used to test that software meets its functional requirements. White-box testing also called structural or clear-box testing involves tests that utilize knowledge of the internal structure of the software. White-box testing is useful in ensuring that certain statements in the program are excercised and errors discovered. The existence of code coverage tools aid in discovering what percentages of a system are being excercised by the tests.
   
   More information on testing can be found at the comp.software.testing FAQ .
   
   
4. Design Reviews: The architecture of a software application can be reviewed in a formal process called a design review. In design reviews the developers, domain experts and users examine that the design of the system meets the requirements and that it contains no significant flaws of omission or commission before implementation occurs.
   
   
5. Codified Best Practices: Some programming languages have libraries or language features that are prone to abuse and are thus prohibited in certain disciplined software projects. Functions like strcpy, gets, and scanf in C are examples of library functions that are poorly designed and allow malicious individuals to use buffer overflows or format string attacks to exploit the security vulnerabilities exposed by using these functions. A number of platforms explicitly disallow gets especially since alternatives exist. Programming guidelines for such as those written by Peter Galvin in a Unix Insider article on designing secure software are used by development teams to reduce the likelihood of security vulnerabilities in software applications.

Projects such as the OpenBSD project that utilize most of the aforementioned techniques in developing software typically have a low incidence of security vulnerabilities.

Issues Preventing Development of Secure Open Source Software

One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.

The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including

• complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review
  
  
• developers making improvements to the application typically focus only on the parts of the application that will affect the feature to be added instead of the whole system.
  
  
• ignorance of developers to security concerns.
  
  
• complacency in the belief that since the source is available that it is being reviewed by others.
  
  

Also the lack of interest in unglamorous tasks like documentation and testing amongst Open Source contributors adversely affects quality of the software. However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.

Benefits of Open Source to Security-Conscious Users

Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.

One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.

References

1. Frankl, Phylis et al. Choosing a Testing Method to Deliver Reliability. Proceedings of the 19th International Conference on Software Engineering, pp. 68--78, ACM Press, May 1997. < http://citeseer.nj.nec.com/frankl97choosing.html >
   
   
2. Hamlet, Dick. Software Quality, Software Process, and Software Testing. 1994. < http://citeseer.nj.nec.com/hamlet94software.html >
   
   
3. Hayes, I.J., C.B. Jones and J.E. Nicholls. Understanding the differences between VDM and Z. Technical Report UMCS-93-8-1, University of Manchester, Computer Science Dept., 1993. < http://citeseer.nj.nec.com/hayes93understanding.ht ml >
   
   
4. Miller, Todd C. and Theo De Raadt. strlcpy and strlcat - consistent, safe, string copy and concatenation. Proceedings of the 1999 USENIX Annual Technical Conference, FREENIX Track, June 1999. < http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/ >
   
   
5. Viega, John. The Myth of Open Source Security. Earthweb.com. < http://www.earthweb.com/article/0,,10455_626641,00 .html >
   
   
6. Gonzalez-Barona, Jesus M. et al. Counting Potatoes: The Size of Debian 2.2. < http://people.debian.org/~jgb/debian-counting/coun ting-potatoes/ >
   
   
7. Wheeler, David A. More Than A Gigabuck: Estimating GNU/Linux's Size. < http://www.counterpane.com/crypto-gram-0003.html >
   
   

Acknowledgements

The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo

Comments

To be fair...

[Brian Knotts]

While he undoubtedly has a point, Red Hat, and other Linux distributors, bundle a lot more software than do proprietary UNIX vendors.

That should be kept in mind when trying to draw conclusions from raw numbers of vulnerabilities.

Re:To be fair...

[Surak]

While he undoubtedly has a point, Red Hat, and other Linux distributors, bundle a lot more software than do proprietary UNIX vendors.

There's actually even more to it than just that. :) In Open Source software, because the source code is available, more vulnerabilities are found to begin with.

This is the point Microsoft and others try to make when they say that their closed source model is more secure is that...it's only marginally better at best of course, because whether the vulnerabilities are found or not, they're STILL THERE.

So in comparing raw numbers, no its not a fair contest. There may be 20 exploits found in Debian, and only 12 found in AIX (or whatever the numbers are), but the question is How many more are in AIX that have yet to be discovered vs how many are in Debian that haven't been discovered yet? I'll bet Debian's number is closer to 0 than AIX's.

Another thing to bear in mind: statistics can be maniuplated to say anything you want. :)

But isn't the REAL point....

[linuxrunner]

of opensource the fact that when a vulnerability is found, it is then patched / fixed / hacked / whatever / and then distributed.

I mean, lets be honest, how many of you programmed some code and it worked perfectly the first time? Maybe sometimes, but even the small programs we forget a " or a ; here and there....
This is putting the works of many, many people together to compile a "program" that is larger than anything I could even dream of accomplishing. i.e., there are bound to be flaws we didn't see in the multi-millons of lines of code.

Back to ontopic.... A security hole is found, we can patch it because we can see the code, we can make it BETTER.
Microsoft....
well, you just wait and hope they eventually make a patch, and half the time the patches suck and are re-exploited in a matter of days.

I'm not claiming that opensource is non-vulnerable or exploit-free.... So this article seems somewhat pointless. Anyone who writes code, knows that an exploit free program of this size is just dreaming. What should really be looked at is the amount of time taken to fix and patch a problem.

Just my .02 of rambling

Re:But isn't the REAL point....

[mshomphe]

I mean, lets be honest, how many of you programmed some code and it worked perfectly the first time?

In fact, I've learned that if code works perfectly the first time, something went terribly, horribly wrong....

hummmm not quite

[TCaptain]

The author wants to "expose the fallacy of the belief in the "inherent security" of Open Source software" (many eyes make safer code) and gives the REAL way to make software more secure of which these 3 caught my eye:

Code audits

Testing

Design reviews

Correct me if I'm wrong, but isn't that exactly the "many eyes make safer code" theory? That open source, having the code available, can have more people do code audits, testing and design reviews than a company with closed source can.

In the real world, he's right, those extra eyes aren't necessarily qualified...but still, on AVERAGE wouldn't there be MORE qualified eyes to do this stuff along with the unqualified?

Re:hummmm not quite

[jasonu]

It may be true that "many eyes make safer code", but only if the many eyes actually review the code, which is what the author said. In OSS, there are more qualified eyes with the ability to audit, test and review the code, but that doesn't mean that any those eyes are actually doing it.

This means that OSS has the *potential* to be more secure, but as shown by the article, that potential is not fully realized.

The fix is on the way

[bourne]

The author's point is correct - while any Open Source package may have been audited, it isn't neccesarily audited well or at all.

But flash-back to the recent announcement of the Sardonix Security Portal, which aims to be a central clearinghouse for tracking audits and auditors. The goal is to have a list of 1) what's been audited, 2) who audited it, and 3) what that particular auditor's track record is on other software - were holes found after they said it was clean?

Obviously this is a new project, and it's founded on the ashes of an earlier effort that didn't get much involvement, but it's a big step in the right direction and it's got DARPA funding. And it probably will do much better jobs with Open Source software than with Closed Source.

Ya but....

[nadie]

The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including

* complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review

"Casual Users" are not peers. The term "Peer Review" means that, in this case, the code would be reviewed by other hackers (software engineers), not by the general public.

I am not a hacker, I don't have the skills or knowledge to find security holes in software libre by reviewing the source code. All I can do is use the software, and if I come across a sympton of a problem, I can email the developer to ask what is going on, which often results in a patch within a short period of time.

Re:Ya but....

[swillden]

"Casual Users" are not peers. The term "Peer Review" means that, in this case, the code would be reviewed by other hackers (software engineers), not by the general public.

Hackers/Software Engineers are still "casual users" in most cases. The issue isn't the presence or lack of the general technical knowledge to examine the code, but the effort and focus.

As an example, I'm a programmer with close to 14 years of experience, and a good deal of it focused on engineering of large systems and on security work. I won't go through my CV, but by most anyone's standards I'm eminently qualified to audit code for security defects.

However, when it comes to, for example, Mozilla, I'm unquestionably a "casual user". Why? Because in spite of my extensive experience and knowledge with software systems in *general* I have little knowledge of the inner workins of Mozilla in *particular*. And it matters. A lot. Even though Mozilla is implemented with my most familiar toolset (heavily abstracted C++), it would take me days if not weeks of focused effort to understand the software enough to be able to begin a security audit.

I know this because a few months ago I attempted to fix a bug that had been bothering me for some time. Although I found the Mozilla code to be well-written, nicely structured and generally easy to work with, it still took me almost two full days to understand it enough to correct that one small defect. I probably spent too much time in random curiosity-driven wandering, but even factoring that out it was a *lot* of work.

Doing a security audit is an undertaking on a completely different scale from adding a feature; it requires a fairly detailed understanding of large chunks of the code, and a thorough high-level understanding of how the modules fit together.

This is not to say that closed source is better, because all of this analysis is, for practical purposes, impossible with closed source. However, don't confuse possession of deep technical skills with deep understanding of a particular piece of software. A hacker who isn't a casual user of most of his software is a hacker who doesn't use much software :-)

README, Changlog, LICENSE, AUDIT... huh?

[kindbud]

I use vsftpd, (vs stands for "very secure" and is a goal, not a declaration of its status). Included with the source are a number of explanatory files you are familiar with: README, INSTALL, Changelog, LICENSE. There is another you probably haven't seen: AUDIT. AUDIT lists each source code file and a rating of 1-5 to indicate how much scrutiny it has received from other competent parties. 1 indicates no scrutiny and 5 means many competent programmers have reviewed it. Most of the files are rated 2 or 3.

I think this is an excellent idea, one that should be expanded upon by other developers.

Oh, and vsftpd 1.0.1 can be obtained from this ftp site at Oxford. It's written on Linux but I run it on Solaris with just a tweak to a #define.

Using published vulnerabilities as yardstick

[Tony]

It's dangerous to simply judge the security of an operating system simply on published vulnerabilities. First, discovering vulnerabilities is a non-trivial task; secondly, some operating systems recieve more frequent audits, resulting in a higher number of discovered vulnerabilities; and thirdly, some operating systems are more-transperant, resulting in a higher number of discovered vulnerabilities.

Take, for example, Solaris. Solaris is the most-used Unix in the world; it is under more external scrutiny than any other Unix, and so you can expect more discovered vulnerabilities than for HPUX or AIX. This doesn't mean AIX or HPUX are intrinsically more-secure; it just means more discovered vulnerabilities on Solaris.

(I don't claim AIX or HPUX is as insecure as Solaris; I'm just saying it's impossible to judge based on number of discovered vulnerabilities.

(And Solaris is pretty secure.)

Then, the BSD and Linux variants are more transperant; anyone can look at the source code, and so possible vulnerabilities are easier to identify.

Nice article, and excellent analysis. My quibbles don't undermine your conclusions; I just *hate* it when people simplify security to number of discovered vulnerabilities.

Security is much more complex than that.

Commercial vs Open Source bugs

[Jordy]

There is quite a big difference between security problems in commercial operating systems such as Solaris and security problems in open source operating systems such as Debian.

The Debian team did not write most of the software that comes with the Debian distribution. Sure they make patches and try to keep things up-to-date, but the software that is in their distribution is included for completeness more than anything else.

Sun on the other hand did write most of the software that comes with Solaris (or at least obfuscated where it came from.) They are directly responsible for security problems with the software they distribute.

When a security problem occurs in Apache, surely it's an Apache security problem that just happens to affect everyone who has Apache installed. If they have Apache installed on Windows, one can't claim it as a Microsoft security bug and blame Microsoft for not auditing every peice of code that happens to compile for their OS.

No one forces the end-administrator to install 99% of the software included with an open source distribution. It is up to the administrator to only install software which they are comfortable with. If the authors of Emacs don't do frequent code audits, don't install it (that's not to say they don't.)

Now... one thing distributions can do to make the end-administrator's job a bit easier is to include statistics along with the application for things like past security vulnerabilities, time since last vulnerability, last code audit, etc. to help them make better decisions about what to install and not to install.

Of course, going the route of only including fully audited code in a distribution just doesn't work. If people need inn, they need inn code review or not. Granted they might take a look at the source while they are compiling it, but the chances of them finding a massive security hole with a curory glance is pretty slim.

That's not to say that distribution vendors are free from blame; especially fully commecial vendors who should at least do some form of audit and mark which packages haven't been audited as 'unsafe,' but come on now... the real blame belongs with the administrator and the developers.

Re:M$ security method isn't new

[eam]

I'm always bothered by the articles which conclude that one OS is less secure because more vulnerabilities are discovered in it than in other OS's. I think it would be better to also consider how the vulnerabilities are discovered.

If we know that RedHat Linux had 54 vulnerabilities last year & Win2K had 42, do we really know anything about the relative security of the two OS's? I would be curious to see the vulnerabilities broken down by how they were discovered. Were they discovered prior to being exploited or as a result of an exploit? It would also be important to know how soon patches were available.

management and people approaches doomed to failure

[markj02]

It's an aphorism among software engineers that languages don't matter, people matter. They claim that you can get a handle on security with better management, better design, better development methodologies. Too bad software engineers have been saying this for decades, and they have completely failed to deliver.

The only known and proven way you can get problems like buffer overflows under control is to use high-level languages and tools that make them impossible. Yes, your programs run slower, but a compromise is much more expensive than a couple more machines. Yes, there will still be plenty of other security holes possible, but we can address those through better tools as well.

Microsoft's management approaches to security are doomed to failure, as are efforts and arguments in the open source community that the open source process magically addresses security problems. Microsoft's real security initiative is their switch to C# and "managed APIs". The open source community should take notice. Unless systems like web servers, file servers, mail servers, and authentication under Linux get rewritten in safe, high-level languages like Java, C#, or others, Linux will be so unreliable relative to Microsoft's and other systems that it will become irrelevant.

(However, given the choice between buggy Microsoft C++ code and buggy open source C++ code, I'll still take the buggy open source C++ code any day--it's easier to fix and fixes come out more rapidly.)