Software will have bugs, but the issues are often in third-party libraries and open source frameworks, not in the code the developers actually wrote. No matter how good the actual code, if these components aren’t managed and checked regularly, the final application remains vulnerable.
“Continued pressure to build high-quality software with ever-shorter development cycles and the ongoing explosion of new architecture patterns, such as microservices, has developers doubling down on the already prevailing dependence of third-party components in enterprise applications,” application security firm Veracode wrote in its 2016 State of Software Security report.
Modern software development is less about writing code from scratch and more about assembling software components and using frameworks. No matter how cutting-edge or slick the application, third-party code is almost always present in modern software. Java applications rely on frameworks to handle visual elements and libraries for data manipulation, and they pay a high price for the shared code: 97 percent of Java applications tested by Veracode included at least one component with at least one known software vulnerability.
Older versions still in use
That’s a grim picture of the use of open source components in software development. The biggest risk didn’t come from obscure or abandoned projects, but from older versions of popular frameworks and libraries. Among the software tested, one-quarter of the applications used a 2012 version of Struts, though the framework has had about three dozen updates since then. The component maintainers may release newer versions addressing bugs and security flaws, but there is a disconnect if the development teams don’t run the up-to-date versions in their code.
The Apache Commons FileUpload library commons-fileupload-1.2.1.jar contains three known security vulnerabilities and was found in 10.4 percent of Java applications. The latest version, 1.3.2, was released in May. The most serious flaw in this library, where specially crafted input could trigger a denial-of-service condition if the buffer used by MultipartStream was not big enough (CVE-2014-0050), was patched in April 2014.
“Many organizations may not even realize that they’ve got a risk in that particular component,” Veracode said.
Not always “safe”
Another Apache Commons Collections library, commons-collections-3.2.1.jar, is the sixth-most common component used in Java applications and was found in 25 percent of Java applications scanned by Veracode. Version 3.2.1 contains the deserialization flaw that was widely publicized in November 2015. The current release is 4.1, and the most up-to-date version for the 3.x branch is 3.2.2, released November 2015. The timing of the report and the patch overlap somewhat, since the report covers all the assessments performed over the past 18 months.
“The high prevalence of the most common vulnerability is understandable given the relatively recent patching of the component,” Veracode said. While it’s likely that some applications were using the most up-to-date component at the time it was scanned, it’s worth asking how many organizations have updated the applications since the flaw was fixed.
Right there is the biggest challenge in managing third-party components: keeping up with versions is an ongoing task. Just because the component isn’t vulnerable when the application is being developed doesn’t mean it will stay that way.
Veracode identified 38 different versions of Struts -- ranging from 2.0.5 to 2.3.24.1 -- used in Java applications. Three of them -- 2.3.20.1, 2.3.24, and 2.3.24.1 -- did not have any known vulnerabilities at the time the data was pulled, and applications using those versions would have been considered “safe.” Those versions now have known vulnerabilities, as Apache released 2.5.5 this month, and the latest version for the 2.3.x branch is 2.3.31.
Same issues, different places
The deserialization flaw in Apache Commons Collections described earlier had a broader impact than commons-collections-3.2.1.jar alone. Among its scans, Veracode found nearly half of the applications had some form of vulnerable Apache Commons Collections libraries, including versions 2.0, 2.1, 2.1.1, 3.0, 3.1, 3.2, and 4.0. Less than 2 percent used a patched version of Apache Commons Collections (version 3.2.2 or 4.1).
That doesn’t even include the fact that other libraries using Apache Commons may also be vulnerable to deserialization exploits. SourceClear has previously warned that the vulnerability may affect popular components such as Apache Hadoop Common and Jasper Reports.
The problem isn’t in third-party code alone. Veracode checked for unsafe deserialization, similar to the one found in the Apache Commons Collections, in the customer’s Java code, and found the vulnerability in 24 percent of developer-authored code. That figure jumped for commercial software, where the vulnerability was in 41 percent of all applications.
“Newly discovered vulnerabilities are rarely only in open source code; you need to be able to look for them in closed source, as well,” Veracode said.
Know the ingredients
All it takes is one popular library with a vulnerability because they can be used by other components and applications. If the developers aren’t aware that the component they are working with also depends on the original component, then they don’t know they’ve inherited the risk. A software bill of materials is no longer a nice-to-have, but a necessity, as developers need to know exactly what they are using and assess the safety of that code. Frequent testing helps catch bugs, along with regularly checking and verifying the building blocks to identify other hot spots in the application.
Remember what happened with the Heartbleed flaw in OpenSSL. It took many organizations weeks to find out if their applications contained the vulnerable software and more time to figure out the remediation plan for each.
The most common component turned out to be aopalliance-1.0.jar, appearing in 39.5 percent of the Java applications tested by Veracode. This AOP Alliance JAR file is a dependency of the Spring framework, so it can be found in any Java application using Spring, and developers may not even realize they've adopted this component. There was a surprising amount of XML and J2EE web libraries listed in the 20 most common components, suggesting many of them are dependencies of other libraries and frameworks.
While commons-collections-3.2.1.jar was widespread, different industries varied on which vulnerable third-party components were employed. The technology industry was more likely to have Java applications using Spring libraries from the vulnerable 3.1.1 release, while government had more instances of vulnerable Strut components. Health care and financial services were more likely to have applications using vulnerable Apache Batik libraries for displaying, generating, and manipulating Scalable Vector Graphics images. Retail and hospitality were even at more risk, as a number of their applications relied on Spring libraries from the 3.0.5 release.
Attackers don’t need to find a security vulnerability for each application when they can focus on a single flaw in a widely used component to exploit millions of applications.
“Security teams need to encourage and facilitate application developers in paying attention to the composition of their applications and keeping open source libraries up to date,” Veracode said.
This isn’t an issue security teams can throw over the cubicle wall and say, “Fix it.” Updating is not as simple as pointing the code to use the latest version. There is a development cost, since every application has to be retested to make sure existing functionality still works and no new bugs are introduced with the new version. Features get deprecated, which means applications need to be rewritten -- even redesigned -- to accommodate the change. Security teams and developers have to work together to identify problematic components and resolve the issues accordingly.