(No) Vulnerabilities in Common Java Libraries?

Image credit: Photo Pexels & Bug on pixabay

TL;DR One can find (almost) no vulnerabilities for popular Java libraries, e.g., apache-commons, google-guava, in the CVE and NDE database. See Chart
Are Java libraries secure by default?
Does no one reports vulnerabilities in Java libs?


(Almost) all software applications make use of third-party libraries or frameworks 1. Vulnerabilities in third-party libraries or frameworks can cause any threat to your application, e.g., DoS, intrusion, spoofing, etc.
In theory, it should be easy to figure out if your application is vulnerable. You determine your application’s dependencies and check if vulnerabilities are published in common databases, e.g., CVE.
In reality, you have to check your dependencies, their dependencies, and so on. After determining all application’s transitive dependencies’ versions, you have to search through the CVE or NVD databases.
Finally, you are (hopefully) able to determine whether your application uses vulnerable third-party libraries or not.

However, you DO NOT know for sure if your application is affected by a vulnerable dependency. If the vulnerability is located in a function your application does not use, the application may not be affected at all.

To cope with this problem, I’m currently trying to link a published CVE vulnerability to a corresponding code location, e.g., a specific method, or a specific class. Based on the linkage, I want to deduce whether an application is vulnerable because it uses vulnerable methods

CVE-Search – Crawling CVEs & CPEs

As a first step, I checked how to crawl the CVE and NVD databases efficiently. A nice and easy to use python script is CVE-Search. It mirrors the CVE and NVD databases within a local MongoDB installation and supports several query formats.
A useful feature is querying CVE’s by their Common Platform Enumeration (CPE). A CPE is a structured naming scheme to identify applications effectively, using a scheme similar to a URI. Based up on the scheme o/h/a:vendor:product:version, o = operating system, h = hardware, a = application, each CPE uniquely identifies a product published by a vendor with a specific version.
For instance, the CPE of Apache Tomcat 9.0.0 has the form cpe:2.3: a:apache:tomcat:9.0.0.

CVE-Search – Query CVEs by Vendor

Using CPEs one can effectively query CVEs by vendor, e.g., apache:

./bin/search.py -p a:apache:

In result, you will receive all CVEs that target any apache product.

CVEs in JSON

Using the command line switch -o cveid/json/cvs/html, CVE-Search returns the results in different output formats. The nice thing is that when generating json, one can directly pipe the output into the command line utility jq.

Using jq, one can first collect all unique CVEs by CPE for the the vendor apache:

 ./bin/search.py -p a:apache: -o json | jq -c '. | .id + " " +  .vulnerable_configuration[0]'  > apache_cves

Side-Note jq -c '. | .id + " " + .vulnerable_configuration[0]' returns the .id (cve identifier) and the first CPE of the array vulnerable_configuration. The array vulnerable_configuration may contain multiple CPE entries, e.g., if multiple versions of an application are vulnerable.

The result contains entries of the form:

"CVE-2012-1089 cpe:2.3:a:apache:wicket:1.4.0"
"CVE-2012-0047 cpe:2.3:a:apache:wicket:1.4.0"
"CVE-2012-0022 cpe:2.3:a:apache:tomcat:5.5.0"
"CVE-2011-4858 cpe:2.3:a:apache:tomcat:5.5.35"
"CVE-2017-12608 cpe:2.3:a:apache:openoffice:4.0.0"
"CVE-2017-12607 cpe:2.3:a:apache:openoffice:4.0.0"
"CVE-2017-9806 cpe:2.3:a:apache:openoffice:4.0.0"

Since we are only interested how often a certain product occurs as a vulnerable configuration, we have to strip the output down using Unix command line tools.

To count how often a particular product (ignoring its version) is subject of a CVE, we run the following command:

cut -d' ' -f2 apache_cves  | cut -d: -f5 | tr -d '"' | tr -d | sort | uniq -c > number_of_entry_per_product
  • cut -d' ' -f2 apache_cves, splits each line at a whitespace and returns the second column (the cpe), e.g.,
    cpe:2.3:a:apache:wicket:1.4.0
  • cut -d: -f5, takes the results and splits each line at the : character and returns the fifth column (the product), e.g., wicket
  • tr -d '"' | tr -d, removes any “ character and whitespace
  • finally, sort | uniq -c, counts how often one product is mentioned. Note that unique requires a sorted input.

Results for Apache

The chart shows the results for querying the CVEs using CPEs by vendor apache. Products with <= 3 entries are deleted (in Total approx 120 products are deleted)

The chart shows that most vulnerabilities can be found in the components, http_server, tomcat, and structs. However, there are only <=4 vulnerabilities for the popular Java library apache commons (there exists no bar in the chart). Similar, I could not find vulnerabilities for the popular Java library guava.


Are vulnerabilities in Java libs uncommon?
Or are vulnerabilities in Java libs not reported?


Related