Open Source Software and Security

by Stuart Yeates on 1 September 2004 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.

Introduction

Computer security is the process of balancing the security requirements of a computer system with requirements for price, usability, user training and reliability. When considering software, it is natural to ask what impact the adoption of open source software has on this balance.

In and of itself, open source software is neither more nor less secure than closed source software. There are famously secure examples of both open source software and closed source software just as there are infamously insecure examples of both open source software and closed source software. Open source does affect the security balance in a number of ways, but the influence of these effects very much depends on the specific circumstances involved.

The source code is available to all.
The availability of source code is a defining characteristic of open source software, but is not an unalloyed blessing:
  • Attackers can examine the source code for vulnerabilities to exploit. This can also be an issue with closed source software whose code is sometimes leaked, as was the case with the illegal posting of Microsoft Windows 2000 source code. There is a long history of leaks of source code and algorithms, including the COMP128 encryption algorithm used in GSM mobile phones.

Defenders can examine the source code for vulnerabilities to fix. This commonly happens in one of two scenarios. The first—searching for a specific vulnerability that is being actively exploited—is relatively easy because the exploit can be reverse engineered and when the vulnerability is fixed and the exploit stops working it is clear that the vulnerability has been fixed. The second—searching for vulnerabilities that are not being actively exploited—is a much harder and more open ended task. Effort tends to focus on high-profile code with obvious security implications and these sections of code are normally secure, but a flaw in almost any part of the software can cause a vulnerability and finding these involves examining all of the source code, which may run to millions of lines of source code. Finding and fixing vulnerabilities is an effective way for open source contributors to gain the respect of their peers, so many contributors are motivated to look through sections of the code for vulnerabilities.

Anyone can contribute to the source code.
Another defining feature of open source software, the ability of anyone, anywhere to contribute source code is a double edged sword:
  • Attackers can attempt to add vulnerabilities to the source code. To prevent this most open source projects accept contributions only from trusted contributors. All other contributors have to have their contributions approved by a trusted contributor. The process of becoming a trusted contributor varies, but often involves long-term commitment to a project and the exchange of cryptographic keys so that trusted contributors can communicate securely. The use of version control systems allows tracking of which contributor makes which changes, when and the reason they give. Should a contributor be found to have introduced a vulnerability, all of their contributions can be isolated, examined and, if necessary, purged.
  • Defenders can contribute fixes to vulnerabilities—the process of finding and fixing vulnerabilities is not limited to the resources and office hours of a single company, but the resources of the users of the software. A result of this is that fixes for known or actively exploited vulnerabilities tend to be issued substantially faster for open source software than for closed source software.
Malware writers target large pools of uniform, poorly maintained computers.
Malware includes viruses, worms, trojans, spyware, rootkits and other software that have deliberately malicious effects or side effects.
  • Currently, open source applications and operating systems tend to be relatively diverse (one consequence of being able to modify the source code is that people do), relatively well maintained (because of the technical barriers to using much open source software it tends not to be the software of choice for complete beginners) and a relative minority (again because of the technical barriers); all these factors make it a poor target for the writers of malware.
  • The technical barriers to the use of open source are being lowered by better documentation and user interfaces, the diversity is being reduced through standardisation efforts and it is becoming widely used; these are progressively undermining the factors which make it unattractive to malware writers.
  • Acceptance of input from non-professionals and emphasis on skills development in open source communities is likely to lead to an increasing number of individuals with the skills to write malware but without the professional ties which might prevent them from writing and releasing malware. This may lead to a long-term increase in malware.
Patented and trade-secret algorithms are largely unavailable to open source projects.
Patents and trade-secrets are used by companies to protect their place in a marketplace. They are viewed with distaste by the free and open source movement.
  • A number of important algorithms, particularly cryptographic algorithms, are patented or are trade-secret and thus unavailable to open source projects, since they are normally unable to meet even the most liberal licensing requirements. Patented algorithms eventually enter the public domain (as the widely-used RSA algorithm has), but trade-secret algorithms remain permanently unavailable.
  • Trade-secret cryptographic algorithms have a long history of being both weak and leaked to the public. The tendency to weakness is due to the fact that the only known reliable way to determine the strength of cryptographic algorithm is to have a large number of cryptographers examine it—which is not possible to do while keeping it a trade-secret.
Open source software may not be tested for security vulnerabilities.
Formal testing programs are used to great effect by many companies as part of quality programs to reduce software defects.
  • Open source projects rarely have the rigid infrastructure required for quality programs such as ISO 9000 implementation, but many of the methods used to implement ISO 9000 quality programs for software are amenable to automation. These include regression testing, unit testing and many compile-time code analysis tests. Most sufficiently large open source projects and several open source support sites (such as SourceForge) have automated methods for running such tests. In addition many open source projects have contributors who use the software in ISO 9000 contexts and perform checks within the context of their employer’s organisation rather than the open source project, but feed bug fixes back to the project.
There are so many versions of open source software that making sure a bug is fixed in all of them is impossible.
Anyone can make changes to and customisations of open source software and a sufficient number do that it can lead to confusion over which bugs affect which versions.
  • There can be a confusing number of versions of open source software, but generally distributors (who package open source software into usable systems) have tools that allow tracking of what software is installed and there is an automated or semi-automated update of the software when security updates appear.
  • The freedom to change also allows security specific customisation to be undertaken. Perhaps the best example of this is the Security Enhanced Linux project, undertaken by the USA’s National Security Agency, which provides a significantly larger set of security features, at the price of significantly higher maintenance and operating overhead.
  • Similar issues are faced by commercial companies who support several products. This is especially true of hardware vendors, for whom continuous upgrade to the current versions is not an option.
  • The Common Vulnerabilities and Exposures system, a vendor neutral system which provides a dictionary of vulnerability identifiers, effectively solves these problems for open source, closed source and mixed systems.

The above points show that open source is not a magic bullet for security but can directly influence security trade-offs in complex ways.

Links:

Related Information from OSS Watch: