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:
- 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.
- 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.
- 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.
- Similar - a new vulnerability that is the same or similar to another known vulnerability but that is now found in a different library.
- 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.
- 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.
- 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
- CVE's make up a small percentage of the disclosed vulnerabilities
- This means the full dependency graph i.e. the direct and transitive dependencies like Apache Commons Collections
- Like these issues we disclosed in Handlebars
- Like this issue we disclosed in Spring Social
- 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.
