name">Why open source software isn't as secure as you think
A failure to spot a necessary validation in OpenSLL code be=
fore an update caused the Heartbleed bug
ens/articles">Paul Rubens (CIO (US)) on 13 June, 2014 08:56
lass=3D"">The ainst_the_OpenSSL_Heartbleed_Flaw">OpenSSL Heartbleed fiasco
proves beyond any doubt what many people have suspected for a long=20
time: Just because open source code is available for inspection doesn't=
mean it's actually being inspected and is secure.
an important point, as the security of open source software relies on=20
large numbers of sufficiently knowledgeable programmers scrutinising the
code to root out and fix bugs promptly. This is summed up in tp://en.wikipedia.org/wiki/Linus%27s_Law">Linus's Law: "Given =
enough eyeballs, all bugs are shallow."
look at what happened with OpenSSL. Robin Seggelemann, a German=20
programmer from Munster University, updated the OpenSLL code by adding a
new Heartbeat keep-alive function. Unfortunately, he missed a necessary
validation in his code to check that one particular variable had a=20
The member of the OpenSSL=20
development team who checked the code before the update was released=20
also missed it. This caused the Heartbleed bug.
reviewer, even a handful of reviewers, can easily miss a trivial error=20
such as this if they don't know there's a bug to be found. What'=
worrying is that, for two years, the Heartbleed bug existed in OpenSLL,=20
in browsers and in Web servers, yet no one in the open source community=20
spotted it. Not enough eyeballs scrutinised the code.
ommercial vendors don't review open source code
alarming is that OpenSSL was used as a component in hardware products=20
offered by commercial vendors such as F5 Networks, Citrix Systems,=20
Riverbed Technology and Barracuda Networks - all of whom failed to=20
scrutinise the code adequately before using it, according to Mamoon=20
Yunus, CEO of Forum Systems, a sec=
ure cloud gateway vendor.
would think that it would be my responsibility as a vendor, if I=20
commercialise OpenSSL, to put my eyeballs on it," he says. "You h=
take a level of ownership of the code if you build a company based on an
open source component."
Instead, Yunus believes
vendors just regarded OpenSSL as a useful bolt-on to their hardware=20
products - and, since it was open source, assumed other people were=20
examining the code.
"Everyone assumed other=20
eyeballs were looking at it. They took the attitude that it was a=20
million other people's responsibility to look at it, so it wasn't t=
responsibility," he says. "That's where the negligence comes =
in from an=20
open source angle."
suggests that commercial vendors should run effective peer review=20
programs for any open source code that they use, run static and dynamic=20
analysis tools over it and "fuzz" the code to ensure it's as =
possible. "What have these companies been doing for the last 10 or 15=
years? If I were them, I would be taking a long, hard look at QA=20
In fact, Yunus questions whether OpenSSL =
should ever have been written in a relatively ogyreview.com/review/527956/imposing-security/">low-level language such as =
C, echoing security expert hives/2014/04/more_on_heartbl.html">Bruce Schneier
by suggesting it could be seen as "criminal negligence" to use a=
language that lacks memory management for such a security sensitive=20
Jeffrey Hammond, a security analyst
at Forrester Research, contradicts this view. He points out that=20
performance is a key attribute of OpenSSL as it has to deal with huge=20
volumes of packets.
"If you have access to=20
memory you are going to be open to some types of attacks, but you get=20
the performance," Hammond points out. "I wouldn't say they sh=
have developed OpenSSL in C, but it's true that with performance comes=
OpenSSL, Truecrypt show limits of=
open source code review
problem facing many open source projects - and the reason it's hard to=
blame Seggelemann or the rest of the OpenSSL team - is that carrying out
a rigorous code security review is immensely time consuming and=20
requires a high level of skill. That means it's very expensive.
is illustrated by another open source project: The TrueCrypt encryption
program. The code has been open to anyone who cares to look at it since
the project started 10 years ago - but it's only very recently,=20
following fundraising campaigns on Indiegogo and Fundfill that yielded=20
US$60,000, that the code has undergone a proper security audit.
An initial cryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Secu=
into just the bootloader and Windows kernel driver of the program=20
identified 11 vulnerabilities, said that the quality of the source code=20
was bad and pointed out that compiling TrueCrypt from source required=20
using outdated (in one case, 21-year-old) and unsigned build tools that=20
could be modified maliciously and that are hard to access from=20
The tedyet.com/">code auditors
said, "Overall, the source code for both the bootloader and the Windo=
kernel driver did not meet expected standards for secure code. "
worrying is that this only came to light after funds where raised to=20
hire the resources to carry out a code review. The open source community
had plenty of opportunities to do this over the last 10 years - but the
truth is that the community doesn't have the time, skills or resources=
(including money) to do the job properly.
A new problem wi=
ll affect the security of OpenSSL going forward, too: The code is being for=
ked, thanks to an initiative called Li=
breSSL led by the OpenBSD
team. LibreSSL is intended to be a stripped down version of OpenSSL; in
the first week of the LibreSLL project, more than 90,000 lines of code=20
were removed, including those supporting operating systems such as VMS=20
The problem, simply stated: Since it's
easy to see what's being removed from LibreSSL, and which bits are=20
being replaced as they're deemed insecure, OpenSSL users are left=20
exposed to malicious hackers who may exploit the weaknesses that=20
LibreSSL discovers and removes - that is, unless the OpenSSL project can
keep up with LibreSSL's progress.
obscurity is never a good idea, but once vulnerabilities are made=20
public, they need to be fixed right away. It's not clear that the=20
OpenSSL team is in a position to do that - it's said that the project=
only had one full-time maintainer - or that software and hardware=20
products that use OpenSSL will necessarily be updated promptly even if=20
the OpenSSL software itself is.
Taking open source secu=
rity seriously after Heardbleed
good news for those concerned about the security of open source=20
projects like OpenSSL is that help could be on its way in the shape of=20
the initiative">Core Infrastructure Initiative (CII),
a new project founded by the Linux Foundation in response to=20
Heartbleed. Its purpose is to funnel needed money into software projects
such as OpenSSL that are critical to the functioning of the Internet.
global economy is built on top of many open source projects," says Ji=
Zemlin, the Linux Foundation's executive director. "We will now be=
to support additional developers and maintainers to work full-time=20
supporting other essential open source projects."
from the CII may also include funding for security audits, computing=20
and test infrastructure. So far, about US$4 million has been pledged=20
over the next three years by companies including Google, Microsoft and=20
Paul Rubens is a technology journalist based =
in England. Contact him at paul-at-rubens.o=
Evan M. Inker