AnsweredAssumed Answered

Responses to upstream security vulnerabilities

Question asked by jamesrgrinter on Apr 27, 2017
Latest reply on May 24, 2017 by mufeed

I have a two-part question about responses to upstream security vulnerabilities, by which I mean dependencies that may be subject to reported issues and vulnerabilities. We run our own Java and Scala project dependencies through the OWASP dependency-checker, that flags possible matches against the published CVE database (part of the NIST National Vulnerability Database).

 

The warnings we see are usually against the many dependencies of the Apache HBase and related JARs. I'm specifically concerned with the MapR variants, as these are the ones we must use in order to connect to a MapR cluster.

 

Picking apart and understanding whether the vulnerable package or classes are actually used by either HBase or MapR code, or has been inadvertently used by one of our developers in our own code because their IDE revealed it to them, is difficult and time consuming!

 

Just last week, it was CVE-2016-4970, a vulnerability in a Netty library, pulled in by org.apache.hbase:hbase-common (1.1.1-mapr-1602), in turn required by com.mapr.fs:mapr-hbase (5.2.0-mapr)

 

This week, even more vulnerable components show up with CVE-2016-7051, due to a vulnerability in earlier Jackson (XML) libraries (which, amongst the many upstream libraries that use it, the Apache HTrace project decided to include within their distributed JAR.) 

 

1. What do others do to address such issues?

 

2. Do MapR perform their own analysis of such upstream vulnerabilities, and if so how/where do they publish it? It doesn't look like the recent "5.2.1-mapr" updates address these particular vulnerabilities (they seem to still reference the same, vulnerable, '1602' builds of hbase-server, but would it have been documented clearly if it did?

Outcomes