A recent round of flaws discovered in open-source software has reignited concerns that security is getting bypassed in the rush to continue expanding the large and extremely popular code base used by millions.
For instance, although the Java-based Spring Framework was criticised by security researchers in January as having a major flaw that allowed remote-code execution by attackers against applications built with it, the updates to Spring this week don't address this security problem.
"Unfortunately, this is the way a lot of open source vulnerabilities go," said Jeff Williams, CEO at Aspect Security, which pointed out two months ago that the "expression-language" feature in Spring should be disabled until the issue related to potential remote code execution is remediated. But the updates to Spring out this week don't address this problem, though they do expand Spring functionality. Spring Framework is managed under SpringSource, a division of VMware.
"They are busy with actual functional stuff and so their incentives are always to minimise the importance of security issues," said Williams.
However, other researchers counter that the focus on security varies considerably across free or open-source software communities and many of them, in fact, do a good job in addressing security issues.
"It's handled very different between open-source projects," said Vincent Berg, researcher at security firm IOActive. "There are projects that have a very active approach to it. The big Linux distributions and the different BSD flavors tend to do a pretty good job." The Ruby on Rails Web application software project also recently moved quickly to make needed updates for security purposes, Berg said.
He says his impression is that better handling of security issues in open source seems to come from those that provide users with mailing lists about security which users are advised to subscribe to, and "most of these distributions have dedicated security contacts."
"These contacts can generally be reached by a dedicated security mailing list, which tends to be non-public," he said. After analysis, there's an effort to reach agreement on whether there's a security-related issue and fix it.
Berg also says projects like Debian and most other big Linux distributions and FreeBSD seem to usually report bugs that are reported to them to "upstream package maintainers."
"Say someone reports a bug in Firefox not to the Firefox people but to the Debian people then the Debian people will handle it as their first point of contact but they will loop in the Firefox folks to determine a joint approach," said Berg.
"A project like Firefox uses their standard bugzilla bugtracker and I've got personal experience with reporting security bugs to them," he said. "They tend to be really fast in responding to a bug report (security bugs will be marked private as default so that only the reporter and the security team can view it)" before delivering the bug fix.
There have been plenty of serious security issues with Firefox products over the years, according to the recent study entitled "25 Years of Vulnerabilities" done by security firm Sourcefire, which analyzed both open-source and proprietary vulnerabilities reported to two public databases. The Mozilla Firefox browser stood out as having the largest number of high-severity vulnerabilities, second only to MicrosoftWindows XP [see graphic].
Firefox had 433 vulnerabilities rated high severity and critical based on the Common Vulnerabilities and Exposures (CVE) database and the second source, the National Vulnerability Database from the National Institute of Standards and Technology. High-severity vulnerabilities mean attackers can potentially fully compromise the user's machine. And in general, three Mozilla products earned the dubious distinction of making the Sourcefire report's list for "Top 10 Products with Critical Severity Vulnerabilities."
"In fact, the top three spots for critical vulnerabilities are held by products from Mozilla," the Sourcefire report states. The Sourcefire report also indicated that in comparing Linux to Windows or the Mac OS in terms of products, Linux scores at 1,752 vulnerabilities in comparison to 1,114 for Windows and 827 for the Mac OS versions.
As with proprietary software, there are plenty of serious vulnerabilities to be discovered. In open source, according to some researchers, the bigger problem is that there is now a widespread use of flawed open-source code. And some say it's often way too hard to even find out what the security issues are.
Ryan Berg, chief security officer at Sonatype, said it's not just serious problems like the severity of the Spring Framework "expression-language" flaw that are of deep concern.
"To me, the bigger issue is it's extremely difficult to ascertain the security of open-source components," he says. "We're seeing an unprecedented amount of usage of flawed open-source software."
Sonatype is a company that provides component lifecycle management products, and it also operates the Central Repository for open-source components. It houses more than 400,000 components, serving up more than 5 billion requests per year for 60,000 organisations.
The open-source community needs to make it simpler and more transparent to report issues and publish findings about security in a way that's more discernible, says Sonatype's Berg.
"We get the CVE feeds, but there are unreported issues," he says, noting that the dark side is that vulnerabilities are being discovered but remain generally unknown. But the demand for open source is so strong that developers just keep downloading and downloading it, and it's become a vital part of enterprise code development and commercial products as well.
Downloading flawed open-source code brings with it "issues from a legal perspective," says Rami Sass, CEO of WhiteSource Software, a company that offers open-source lifecycle management software used by vendors and enterprises to track their usage of open-source libraries and legal status to adhere to internal corporate policy.
While the emphasis at WhiteSource is primarily on tracking open-source libraries and legal issues rather than purely technical aspects of security, Sass says he thinks "there's a special exposure" that comes with open source because hackers can look at it to hook into vulnerabilities. He also notes that it's commonplace for companies to develop and sell commercial software using open-source libraries and many of those libraries become out of date but aren't monitored for that.
A common problem is that companies, both vendors and enterprise, lose track of what they're even using in terms of open-source code, Sass says. But there's now a pushback among some businesses to press vendors to disclose their open-source usage. For example, "banks and insurance companies are already introducing clauses with vendors to provide them with a full list of open-source and the indemnification."
IOActive's Berg says his firm also sees its customers frequently taking up the open-source security question.
"The advice I tend to give IOActive's customers, where we deal with this issue regularly, is that before using any new external [free or open-source] component, the company has to do an extensive analysis of the component to answer some questions. What is the quality of the code? Does the project respond to upstream bugfixes and issues quickly? Do they have dedicated security contacts?"
Depending on the analysis in any given situation and the license the component was released under, the company anticipating use of open-source code may decide "to simply fork the software and maintain a separate fork internally," says IOActive's Berg. "This gives one the benefit of not having to disclose security issues to the upstream package authors," which may be "preferable" from the company's point of view.
This, however, may well be considered "bad form" by both companies and the open-source people working on the code because open-source communities prefer companies using open source to report back on serious issues that crop up, he adds.
Use of free and open-source code for either corporate-rolled or vendor-made products does bring the risk and responsibility that "one has to keep track of outside security issues and back port them to the version of the library that the company is using," IOActive's Berg notes. "If the libraries move too far apart, this is an extra burden on the company." In any event, he says, playing "closely and openly" with the free and open-source community is needed.