Software Security: Open Source vs Closed Source – The Debate.

Abstract

The use of computers has grown significantly in the last few years, as has the use of networked computers via the Internet. Security is becoming an increasingly important issue as numbers continue to grow and users become more reliant on their computer systems. Software and hardware vendors alike are engaged in a battle against a veritable army of problems – hackers, worms, viruses, Trojans, and more. Along side this conflict rages the competition between two models of software development – open source and proprietary. Long-time operating system monopolist Microsoft is feeling the heat as freeware alternatives become more popular, and both are waging a public relations battle, a significant aspect of which is security. Debate rages as security pundits, experts and amateurs ponder the issue of whether or not open source software is inherently more secure than proprietary software. This document examines this issue, looking at the advantages and disadvantages of the open source model with respect to security issues. The different attitudes between the various closed and open source software vendors are examined, and possible solutions are offered that might allow proprietary software companies to counter issues raised by the open source movement.

Software Security

Computer security is rapidly becoming one of the most important aspects in modern society. The large number of companies that are now reliant on their computer systems to carry out their day-to-day business activities is now at an all-time high, and thus so is the risk that these companies are exposed to by poor security. In 2001, the Code Red worm that hit the Internet caused an estimated US$2 billion in damages [1], and was a harsh lesson to many about how dependent they are on computer security for their livelihood.

As a result, vendors are spending more money than ever in order to focus on security. Microsoft’s Bill Gates stated in an email to staff that “Trustworthy Computing [Microsoft’s new security policy] is the highest priority for all the work we are doing”, and then reportedly went on to spend over US$100 million on enforcing this policy [2].

The open source movement is taking security no less seriously, though from a different perspective. Open source security advocates argue that this model is more secure for a number of reasons. Proprietary software vendors generally argue that open source is not as secure as many make it out to be, and that there are many other factors involved.

The key argument of the open source security advocates is the “many eyeballs” effect – simply, the more people able to peruse the source code for software, the more likely bugs that might cause security issues are to be found. They assert that this independent peer review provides more opportunity for security-related bugs to be found before they cause problems.

Another advantage of this model is that the nature of the Internet helps to promote such activity to take place. Communities can communicate in real-time about potential security issues, examining them as they’re discovered, investigating potential risk and impact of such problems, and finally creating a fix and making it available for distribution as soon as possible.

Red Hat, developers of a popular Linux distribution that is being promoted as a viable open source alternative to commercial operating systems, are strong advocates of open source security. In addition to approving of the source review policy, Red Hat also believes that:

The code accessibility that defines and reinforces the open source development model supports the creation of standards, a more responsive development process, and faster vulnerability disclosures. [3]

Full and fast disclosure is also argued for by open source advocates. The maintainers of the OpenBSD project, for which security is the single most important aspect, believe that full disclosure is critical as it allows security-conscious developers the opportunity to become immediately aware of problems in software and the chance to fix them as soon as possible [4].

Full disclosure works very well in conjunction with the open source model, as seen in the “Ping of Death” exploit cited by the Open Source group [5]. After this exploit was published, the Linux community had a patch out addressing it in less than three hours [6]. The vulnerability was identified, the source code was available, and someone was able to implement a fix and publish it almost instantly. Users of proprietary software had no choice but to simply wait for a patch from their vendor, being vulnerable to the exploit while they waited.

Closed source advocates are quick to point out problems with this model, such as the fact that it also offers malicious users the opportunity to find bugs for the sole purpose of exploiting them, which could lead to untold havoc if the affected software was in use by a large number of users and took a long time to be identified. The open source movement is quick to say that malicious users can still exploit binary code, but this is generally recognised as much more difficult - Elias Levy, the CTO of SecurityFocus and former moderator of BUGTRAQ, stated that in the same time that it would take to find an exploit in a binary-only piece of software, someone could search ten different open source applications for common, known programming bugs (such as buffer overruns) that frequently lead to exploits. [7]

Microsoft takes a somewhat contrary position to their rivals at Red Hat. Microsoft’s Chief Technology Officer Craig Mundie states unequivocally that broad access to source code does not inherently lead to secure software. [8] However, he goes on to state that Microsoft does not believe in a “security through obscurity” approach:

“…we believe that it is possible to realize the benefits claimed for a ‘many eyes’ approach to security by working with as many motivated and capable ‘eyes’ as possible while reducing risks by limiting that community to trusted entities.”

Mundie argues that the people reviewing code are not necessarily qualified to do so, and further states that commercial software companies are more likely to use trusted, skilled employees to handle security-related matters, implying that they have a strong financial incentive to ensure that their products are as secure as possible. Microsoft’s strong focus on security in the last several months is definitely going a long way to backing this up.

This introduces another issue that is voiced frequently, even by open source advocates – that everyone having the ability to read and modify source code does not necessarily contribute to greater security. Many people reading your code may sometimes make it more likely for bugs to be found, but it in no ways guarantees it. This is explained further by Microsoft’s Managing Director of Research, Roger Needham, when he speculates that perhaps these vulnerabilities “are in out-of the way and unglamorous pieces of code, and unless you're being paid to look at it why should you” [9]. An example is an exploit that drew a lot of attention in 2002 - the OpenSSH "Challenge-Response" authentication buffer overflow [10]. A flaw in this open source package (no doubt perused by many developers) still escaped attention, providing a root exploit on a variety of operating systems.

Figure 1 - OS Vulnerabilities by Year

This lack of a guarantee is proven by the number of exploits that are continually reported in open source software projects. Figure 1 displays statistics generated from the BUGTRAQ mailing list, demonstrating the number of vulnerabilities reported for various operating systems. Clearly, open source software still suffers from many vulnerabilities – in fact, Red Hat is nearly on par with the proprietary Windows NT/2000 (though not graphed, data is available for 2001 until August – during that period Red Hat had more vulnerabilities than Windows NT/2000) [11].

A further argument is the possibility that malicious users might intentionally add in exploit or back door functionality into an open source project, cleverly disguised so that it remains hidden. Code that is sufficiently obfuscated could hide an exploit, and would probably be overlooked by the casual programmer looking for exploits.

Companies that choose to keep their software proprietary have several options to ensuring nominal security. The first and foremost is to ensure that their developers follow good practices when it comes to writing software. IBM’s John Viega qualifies this further, saying that developers should be well-educated in application security practices, and that applications should be designed from scratch with security in mind [12].

In order to ensure the fastest possible response in the event of a publicly disclosed exploit, companies need to have a well-defined procedure for dealing with security problems, or they will be placing their customers at risk of having their systems exploited or their services disrupted (not to mention the extra ammunition this would give the open source movement!). Companies that wish to safeguard their reputation and customers will need to ensure they maintain a system for users to submit security-related problems, and have resources set aside to deal with these, immediately if necessary – perhaps by having a programmer who is able to be diverted from his current task to start working on a fix.

Further, merely fixing the problem isn’t enough – creating a patch is next to useless if the customers aren’t aware of the patch or able to get it easily. Developers need to ensure that they have a way to notify their customers directly about important updates that their system may require in order to run securely, and they will need to provide a distribution method (for example, a website) which allows affected customers to easily obtain the fix (Microsoft’s WindowsUpdate service is a great example of such a system).

Ultimately, there is no single conclusion that can be drawn about which model is better – both have their advantages and disadvantages. Open source software offers the possibility of more secure code, but no guarantees – most open source software has had several vulnerabilities over the last few years. Further, there is no guarantee that those reviewing the source code are competent security analysts. It also raises the possibility of third parties tampering with source code. The same is also true of closed source software, of course, but the incentives (largely financial) to ensure that this does not happen are significantly greater. There are measures that both models can take to ensure nominal security. Fortunately for everyone, many vendors are taking such measures since the recent increased focus on software security, which will – hopefully – mean more peace of mind for all.

Appendix

This section contains some personal opinions about the debate which I have formulated based on my experiences in using a wide variety of open source and proprietary software in real-world situations.

Some background – we run a number of web servers, used to provide a variety of online services, including servers for web, email, DNS, ssh, CVS, and many more. Over the years we have continually be evaluating various open source alternatives, largely because we can do so at no cost (where the software is free to download from the Internet). Additionally, we have also obtained a smaller number of commercial software packages (including Windows 2000 server operating systems) and used them for comparison.

Primarily, we have run the Linux operating system for the majority of our services. All of the software we have used on this system has been open source – for example, Apache (http://www.apache.org) as a web server, and qmail (http://www.qmail.org) as a mail server. Security has always been a focus, due to the large number of people that use our services and the fact that we store many items of sensitive data on some of our servers.

Based on my experience maintaining this service, I have concluded that in general, Linux is significantly harder to maintain securely than other operating systems such as Windows or FreeBSD. I am more inclined to believe that this is due to the sheer volume of different open source software that the average Linux distribution installs, most of which has never gone through even a token auditing to ensure that it is secure (as opposed to, say, OpenBSD). Linux, due to its popularity, is also a favourite hacker target.

Red Hat have gone an extra step and provided a utility called ‘up2date’ which attempts to solve this problem by attempting to verify package versions against a local database of ‘known good’ versions. This is fine if you’re installing using Red Hat’s native package format (RPM), but generally speaking we (and many other advanced users) compile from source, which means this measure is next to useless, and we need to keep track of every piece of software that we install manually.

On the other hand, Windows 2000 Server has been a comparatively pain-free experience. The WindowsUpdate service ensures each Windows server we add to our network is patched immediately to the latest versions of all critical system components. While many users complain about the insecurity of Windows as a server product, we have found that by simple use of the WindowsUpdate server and the most token of efforts to lock down the box (for example, stopping unnecessary Windows services) is sufficient to protect the box against the majority of exploits.

We have not had one single security incident on a Windows server – simply by using the WindowsUpdate service and making some simple changes to the default configuration – in over two years. However, during that time, we have had several security incidents in our Linux boxes. Most of the incidents could only have been avoided if we had gone through the source code by hand, or by manually checking each and every package for available exploits – a time consuming task, to say the least.

We have since started slowly migrating away from the more common Linux distributions that we have used in the past for this very reason, and are starting to look at operating systems that have a software policy that is better defined and focuses more strongly on security. Free operating systems are still at the top of our list, although we are now much more inclined to go with FreeBSD or OpenBSD due to their more centrally maintained code bases. Red Hat appears to be trying to follow in the footsteps, although they seem to have a few barriers to get past (such as the issue of RPMs not automatically resolving dependencies) – up2date is a significant improvement and a big plus over most other common Linux distributions and it is good to see this focus from Red Hat.

The research I have done on this assignment has convinced me more than ever that open source does not necessarily mean better security, despite the guarantees of Red Hat and other members in the open source movement. It definitely offers the possibility of better security, but until someone is prepared to actually sit down and audit every line of code in an open source project – something which would not be fun or easy due to the complete lack of standardisation – then it is quite unlikely that open source software will be any more secure than its closed-source alternative.

As an end-user of a variety of software that I consider mission-critical, at this stage I am more likely to go with a reputable proprietary software vendor (such as Microsoft) if I believe that they will offer better security. The last 12 months of activity from Microsoft and their increased focus on security and their diligence in getting out patches and fixes has reinforced to me that they are going to be just as reliable as open source alternatives when it comes to ensuring their software is secure.

References:

1. Watt, Peggy. (2002) Microsoft Outlines Security Policy, PCWorld.com. Available at http://www.pcworld.com/news/article/0,aid,106928,00.asp (accessed 15 May 2003).

2. Smith, D. (2002) Report card: Microsoft's Trustworthy Computing, ZDNet Australia. Accessed at http://www.zdnet.com.au/itmanager/technology/story/0,2000029587,20268906,00.htm (accessed 15 May 2003).

3. Why Open Source Software Can Help Create a More Secure IT Infrastructure, Red Hat, Inc, 2002. Available at http://www.redhat.com/mktg/securitysummit/ (accessed 15 May 2003).

4. OpenBSD Security, 2003. Available at http://www.openbsd.org/security.html (accessed 15 May 2003).

5. FAQ: Advocacy, Open Source Initiative, 2003. Available at http://www.opensource.org/advocacy/faq.php (accessed 15 May 2003).

6. Kenney, M (2003). Ping of Death, Insecure.org. Available at http://www.insecure.org/sploits/ping-o-death.html (accessed 15 May 2003).

7. Elias Levy, 2000. Wide Open Source, SecurityFocus.com. Available at http://www.securityfocus.com/news/19 (accessed 15 May 2003).

8. Mundie, Craig, 2002. Security: Source Access and the Software Ecosystem, Microsoft.com. Available at http://www.microsoft.com/resources/sharedsource/Security/SourceAccess.mspx (accessed 15 May 2003).

9. Needham, Roger (2002). Security and Open Source, Microsoft.com. Available at http://www.microsoft.com/resources/sharedsource/Security/Needham.mspx (accessed 15 May 2003).

10. OpenSSH "Challenge-Response" authentication buffer overflow, Internet Security Systems, 2002. Available at http://www.iss.net/security_center/static/9169.php (accessed 15 May 2003).

11. SecurityFocus VulnStats, SecurityFocus, 2001. Available at http://www.securityfocus.com/sfonline/vulns/stats.shtml (accessed 15 May 2003).

12. Viega, J. (1999). Open source software: Will it make me secure?, IBM DeveloperWorks. Available at http://www-106.ibm.com/developerworks/security/library/s-oss-security.html (accessed 15 May 2003).