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: