By Mark Curphey

Managing AppSec

Share this article:

There are at least seven types of open-source library vulnerabilities that we should all be extremely concerned about. Before describing them it is worth reiterating that simply linking to a vulnerable library in your project doesn’t mean your application will have a vulnerability. That's FUD. You will only have a vulnerability if you are using the vulnerable methods of the vulnerable library in a vulnerable manner. This is important. To know this for sure you need to look at the call-graph of your application and see if there is a call-chain to the vulnerable method in the dependency graph. Listing vulnerable libraries is easy but actually determining a vulnerability is hard.

For every vulnerable library being used we see a very small percentage (single digits) of those projects actually using the vulnerable methods. Another way to read that is by just showing vulnerable libraries there is a 90% + false positive rate.

The seven deadly sins of open-source libraries are:

1. Disclosed Vulnerability - a vulnerability where information is available in public databases such as the National Vulnerability Database in the form of CVEs(1). CVE is a claim based system and claims require secondary analysis, verification, and data enrichment such as the vulnerable versions and the vulnerable methods.
2. Inherited Vulnerability - a new vulnerability that is the result of a library inheriting a library with another vulnerability via its dependency & call graph (both conditions needed)(2). The typical Java library inherits four other libraries and the typical NPM module inherits nine other libraries, making inherited vulnerabilities quite common.
3. Embedded - a new vulnerability that is the result of inheriting a library with a another vulnerability by embedding its code (usually as a result of cut-and-paste or adding a JAR file or XML parser in a parent library). Sites(3) like Conjars make these type of vulnerabilities a growing problem.
4. Similar - a new vulnerability that is the same or similar to another known vulnerability but that is now found in a different library.
5. Reintroduced - the same vulnerability that has been fixed in a previous release of the library but that has been reintroduced in a later version of the same library(4). This is quite common when libraries maintain multiple versions.
6. Zero Days - new issues that have not yet been the subject of disclosure but known about by someone and likely being used by the bad guys in the wild.
7. Half Days - new issues that have not yet been the subject of disclosure but can be found in places like commit logs, change-logs and issue trackers if you know where to look. Half days(5) are often obscured and sometimes hidden but more often than not hiding in plain-sight.

References

1. CVE's make up a small percentage of the disclosed vulnerabilities
2. This means the full dependency graph i.e. the direct and transitive dependencies like Apache Commons Collections
3. Like these issues we disclosed in Handlebars
4. Like this issue we disclosed in Spring Social
5. Tracking half-days requires you to be good at scavenging on the Internet (or have a team working on using ML and NLP to track these things at scale

Note: This post was updated from an original post The Six Types of Open Source Library Vulnerabilities posted last year.

By Mark Curphey

Mark Curphey, Vice President, Strategy Mark Curphey is the Vice President of Strategy at Veracode. Mark is the founder and CEO of SourceClear, a software composition analysis solution designed for DevSecOps, which was acquired by CA Technologies in 2018. In 2001, he founded the Open Web Application Security Project (OWASP), a non-profit organization known for its Top 10 list of Most Critical Web Application Security Risks. Mark moved to the U.S. in 2000 to join Internet Security Systems (acquired by IBM), and later held roles including director of information security at Charles Schwab, vice president of professional services at Foundstone (acquired by McAfee), and principal group program manager, developer division, at Microsoft. Born in the UK, Mark received his B.Eng, Mechanical Engineering from the University of Brighton, and his Masters in Information Security from Royal Holloway, University of London. In his spare time, he enjoys traveling, and cycling.