Open source security proponents have long held to the motto that "given enough eyeballs, all bugs are shallow,"...
but after major vulnerabilities were discovered this year in two major open source software components, OpenSSL and the Bourne-again shell (Bash), is it time to question whether open source code truly delivers security benefits?
Revealed just last week, the Shellshock vulnerability, CVE-2014-6271 and CVE-2014-7169, affected the Bash shell, which is utilized in both the Linux and Mac OS X operating systems as well as a variety of other networking devices. The flaw can be triggered by placing malicious code at the end of a function that is handled by Bash, potentially providing attackers with a bug that can be easily and remotely exploited.
The severity of Shellshock led industry veterans to compare the vulnerability to Heartbleed, the OpenSSL vulnerability uncovered in April that potentially exposed user credentials and encryption keys across the Internet. Shellshock has been described as a noisy vulnerability that gives attackers complete control of a system, while Heartbleed could be exploited repeatedly without leaving a trace. But what both flaws had in common is that they were found in nearly ubiquitous open source software components after going unnoticed for years.
That has led security industry veterans such as Errata Security CEO Robert Graham, who researched Heartbleed and Shellshock extensively, to declare the "many eyes" open source security trope to be dead.
"Just because a bug was found in open source does not disprove the 'many eyes' theory. Instead, it's bugs being found now that should've been found sometime in the last 25 years," said Graham in a blog post. "What we've seen is that, in fact, very few people ever read code, even when it's open source. The average programmer writes 10 times more code than they read."
Open source: Security benefit, nightmare or neither?
While Shellshock and Heartbleed were undoubtedly severe security flaws, experts who spoke with SearchSecurity disagreed over what the bugs mean for the open source security model.
Bill Weinberg, senior director of open source strategy at Black Duck Software, said that Shellshock in particular was caused by the oft-held assumption by developers that if open source software has been around long enough, it must have been vetted thoroughly for security. Even the most widespread software components may not have been subjected to extensive security review, said Weinberg, meaning that the "many eyes" model does indeed fall down when there is a lack of resources dedicated to a project.
Weinberg emphasized that funding issues are hardly unique to open source software projects like OpenSSL, and noted that he has personally witnessed small development teams face the same problems when working on proprietary code. In reality, open source maintains a security advantage, he added, because white hat researchers are largely unable to provide thorough analysis for proprietary code.
"While there is no guarantee of all those eyeballs, the mere possibility makes open source potentially more secure," said Weinberg. "And that's why I would be reluctant to walk back to some closed world of security via obscurity."
Neil Watson, senior partner, architecture and infrastructure at Canada-based Evolve Thinking, agreed with Weinberg that open source software projects are often underfunded despite the role they may play in commercial products around the globe.
The OpenSSL project, for instance, only received about $2,000 per year in donations before Heartbleed was discovered, according to a blog post by OpenSSL Software Foundation co-founder Steve Marquess, and combined with sales revenue from commercial software support contracts and consulting, that tally still never topped $1 million in annual gross revenues. After Heartbleed, donations more than quadrupled and some of the largest tech vendors in the world pledged millions in aid to vital open source projects like OpenSSL.
As a result, such projects are often reliant on volunteers rather than paid staff and can't afford professional security audits. Still, commercial software products can be subject to similar funding limitations, Watson said, and often can't be reviewed by outside researchers because of intellectual property claims.
"In spite of the fact that virtually every high-tech company in existence relies on OpenSSL, virtually none of them had any contributions towards its maintenance," said Watson. "You get these very important projects that are on many cases just taken for granted, and we just assume they work. No one helps them at all."
John Viega, executive vice president of products, strategy and services for security as a service provider SilverSky, said open source software does not pose any more of a security risk than proprietary software, but conversely, it is wishful thinking by open source proponents to consider such code inherently more secure.
All developers face the same problem when attempting to secure code, Viega said -- namely, there is a severe lack of security professionals capable of finding complex coding flaws like Shellshock and Heartbleed. And when experts can be hired, he said it is still impossible for one person to find all of the bugs in even a simple software suite, much less a project as complicated as an OpenSSL.
Viega added that transforming all developers into security experts would be an impossible task, so rather than asking them to secure their own code, the industry needs to provide better automated tools that can help spot major bugs.
"There is a difference between code that is designed well and reviewed, and code that isn't," said Viega. "But that doesn't really correlate at all to open source or closed source."
Resident expert Michael Cobb explains why enterprises should revisit open source software in the wake of Heartbleed and other vulnerabilities, and how to monitor the use of open source components in an enterprise setting.