FRAMINGHAM – A study of how 31 popular open-source code libraries were downloaded over the past 12 months found that more than a third of the 1,261 versions of these libraries had a known vulnerability and about a quarter of the downloads were tainted.
The study was undertaken by Aspect Security, which evaluates software for vulnerabilities, with Sonatype, a firm that provides a Central Repository housing more than 300,000 libraries for downloading open-source components and gets 4 billion requests per year.
“Increasingly over the past few years, applications are being constructed out of libraries,” says Jeff Williams, CEO of Aspect Security, referring to “The Unfortunate Reality of Insecure Libraries” study. Open-source communities have done little to provide a clear way to spotlight code found to have vulnerabilities or identify how to remedy it when a fix is even made available, he says.
“There’s no notification infrastructure at all,” says Williams. “We want to shed light on this problem.”
He adds that Aspect and Sonatype are mulling how it might be possible to improve the situation overall.
According to the study, researchers at Aspect analyzed 113 million software downloads made over 12 months from the Central Repository of 31 popular Java frameworks and security libraries (Aspect says one basis for the selection of libraries were those being used by its customers). Researchers found:
– 19.8 million (26%) of the library downloads have known vulnerabilities.
– The most downloaded vulnerable libraries were Google Web Toolkit (GWT); Apache Xerces; Spring MVC; and Struts 1.x. (The other libraries examined were: Apache CXF; Hibernate; Java Servlet; Log4j; Apache Velocity; Spring Security; Apache Axis; BouncyCastle; Apache Commons; Tiles; Struts2; Wicket; Java Server Pages; Lift; Hibernate Validator; Java Server Faces; Tapestry; Apache Santuario; JAX-WS; Grails; Jasypt; Apache Shiro; Stripes; AntiSamy; ESAPI; HDIV and JBoss Seam.)
Security libraries are slightly more likely to have a known vulnerability than frameworks, the study says. “Today’s applications commonly use 30 or more libraries, which can compromise up to 80% of the code in an application,” according to the study.
The types of vulnerabilities found in open source code libraries vary widely.
“While some vulnerabilities allow the complete takeover of the host using them, others might result in data loss or corruption, and still others might provide a bit of useful information to attackers,” the study says. “In most cases, the impact of a vulnerability depends greatly on how the library is used by the application.”
The study noted some known well-publicized vulnerabilities.
– Spring, the popular application development framework for Java, was downloaded more than 18 million times by over 43,000 organizations in the last year. However, a discovery last year showed a new class of vulnerabilities in Spring’s use of Expression Language that could be exploited through HTTP parameter submissions that would allow attackers to get sensitive system data, application and user cookies.
– in 2010 Google’s research team discovered a weakness in Struts2 that allowed attackers to execute arbitrary code on any Struts2 Web application.
– In Apache CXF, a framework for Web Services, which was downloaded 4.2 million times by more than 16,000 organizations in the last 12 months, two major vulnerabilities were discovered since 2010 (CVE-2010-2076 and CVE 2012-0803) that allowed attackers to trick any service using CXF to download arbitrary system files and bypass authentication.
Discovery of vulnerabilities are made by researchers, who disclose them as they choose, with some coordinated and “others simply write blog posts or emails in mailing lists,” the study notes. “Currently, developers have no way to know that the library versions they are using have known vulnerabilities. They would have to monitor dozens of mailing lists, blogs, and forums to stay abreast of information. Further, development teams are unlikely to find their own vulnerabilities, as it requires extensive security experience and automated tools are largely ineffective at analyzing libraries.”
Although some open source groups, such as OpenBSD, are “quite good” in how they manage vulnerability disclosures, says Williams, the vast majority handle these kinds of security issues in haphazard fashion and with uncertain disclosure methods. Organizations should strengthen their security processes and OpenBSD can be considered an encouraging model in that respect, the study says.
Williams adds that use of open source libraries also raises the question of “dependency management.” This is the security process that developers would use to identify what libraries their project really directly depends on. Often, developers end up using code that goes beyond the functionality that’s really needed, using libraries that may also be dependent on other libraries. This sweeps in a lot of out-of-date code that brings risk and no added value, but swells the application in size. “Find out what libraries you’re using and which are out of date,” says Williams. “We suggest minimizing the use of libraries.”
The report points out, “While organizations typically have strong patch management processes for software products, open source libraries are typically not part of these processes. In virtually all development organizations, updates to libraries are handled on an ad hoc basis, by development teams.”
Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security.
