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=
=20
mean it's actually being inspected and is secure.

It&#=
39;s
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."

But
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
realistic value.

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.

One
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'=
;s=20
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.

C=
ommercial vendors don't review open source code

Al=
so
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.

"You
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=
ave to=20
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=
heir=20
responsibility," he says. "That's where the negligence comes =
in from an=20
open source angle."

">Yunus
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 =
bug-free as
possible. "What have these companies been doing for the last 10 or 15=
=20
years? If I were them, I would be taking a long, hard look at QA=20
processes."

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=
=20
language that lacks memory management for such a security sensitive=20
application.

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=
ould never=20
have developed OpenSSL in C, but it's true that with performance comes=
=20
responsibility."

OpenSSL, Truecrypt show limits of=
open source code review

One
problem facing many open source projects - and the reason it's hard to=
=20
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.

lass=3D"">This
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.

=3D"">

An initial cryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Secu=
rity_Assessment.pdf">report
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
trustworthy sources.

The tedyet.com/">code auditors
said, "Overall, the source code for both the bootloader and the Windo=
ws
kernel driver did not meet expected standards for secure code. "

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
and OS/2.

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.

Security by=20
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=
=20
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

The
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.

Sup=
port
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
Facebook.

Paul Rubens is a technology journalist based =
in England. Contact him at paul-at-rubens.o=
rg.