We are using Spring Boot microservice. In this service we access DSE Graph database. In our pom.xml, we are using following dependencies. Our Security scanning system informs critical vulnerabilities in DSE jar files downloaded by Maven for these dependencies. This blocks our deployment. We need technical support to use proper dependencies in pom.xml.
Dependencies used for Datastax connectivity
snippet of the pom content
The vulnerabilities found are
FasterXML jackson-databind 2.x before 18.104.22.168 mishandles the interaction between serialization gadgets and typing, related to org.apache.hadoop.shaded.com.zaxxer.hikari.HikariConfig (aka shaded hikari-config).
FasterXML jackson-databind 2.x before 22.214.171.124 mishandles the interaction between serialization gadgets and typing, related to com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig (aka ibatis-sqlmap).
FasterXML jackson-databind 2.x before 126.96.36.199 mishandles the interaction between serialization gadgets and typing, related to br.com.anteros.dbcp.AnterosDBCPConfig (aka anteros-core).
CVE-2020-11619 (This applies to Spring AOP. So that might be something they need to look at because they use Spring (not sure if they use AOP jars or not). But that's not driver related)
FasterXML jackson-databind 2.x before 188.8.131.52 mishandles the interaction between serialization gadgets and typing, related to org.springframework.aop.config.MethodLocatingFactoryBean (aka spring-aop)
FasterXML jackson-databind 2.x before 184.108.40.206 mishandles the interaction between serialization gadgets and typing, related to org.apache.commons.jelly.impl.Embedded (aka commons-jelly).
SubTypeValidator.java in FasterXML jackson-databind before 220.127.116.11 mishandles default typing when ehcache is used (because of net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup), leading to remote code execution.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariConfig.
A flaw was discovered in jackson-databind in versions before 2.9.10, 18.104.22.168 and 22.214.171.124, where it would permit polymorphic deserialization of a malicious object using commons-configuration 1 and 2 JNDI classes. An attacker could use this flaw to execute arbitrary cod
A flaw was discovered in FasterXML jackson-databind in all versions before 2.9.10 and 2.10.0, where it would permit polymorphic deserialization of malicious objects using the xalan JNDI gadget when used in conjunction with polymorphic type handling methods such as `enableDefaultTyping()` or when @JsonTypeInfo is using `Id.CLASS` or `Id.MINIMAL_CLASS` or in any other way which ObjectMapper.readValue might instantiate objects from unsafe sources. An attacker could use this flaw to execute arbitrary code.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariDataSource. This is a different vulnerability than CVE-2019-14540.
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to net.sf.ehcache.hibernate.EhcacheJtaTransactionManagerLookup.
This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.
asterXML jackson-databind 2.x before 126.96.36.199 lacks certain net.sf.ehcache blocking.
From the #drivers slack channel (https://datastax.slack.com/archives/C173WTDT4/p1594227185197200) we think the dependencies came from the dse-java-driver-graph version 1.9.0 artifact. The above are all from older versions of jackson-databind.
Creating this JIRA to
track the investigation whether any of the vulnerabilities are in the DSE execution path
provide a fix
First, as of 4.4.0, all of the DSE specific functionality has been merged into the single unified driver, there is no need to pull in any DSE specific graph modules. Second, DSE driver 1.9 is based on the old 3.x OSS driver series. Including both dependencies will likely cause problems at some point as they depend on different versions of the same libraries.
So why are they including both the 1.9.0 DSE graph module and the 4.7.2 Driver?
Yes, they don’t need to use the 1.9 graph module. I think they got the sample code somewhere and thought they had to include the graph module. They confirm they want to use the core 4.7.2.
I updated the title of the Jira to reflect the new/correct problem statement.
In the webEx session today we tried using core 4.7.2 only and still got dependencies to jackson-databind 188.8.131.52 due to Gremlin Core 3.4.5.
DSE core 4.7.2 -> Gremlin Core 3.4.5
Gremlin Core 3.4.5 -> Gremlin-shaded 3.4.5
Gremlin-shaded 3.4.5 -> com.fasterxml.jackson.core » jackson-databind (optional) 184.108.40.206
Can we check the above if these are applicable to DSE?
Java driver core version 4.7.2 declares an explicit dependency on Jackson Databind version 2.11.0, which is not vulnerable to any of the listed CVEs. If an application depends on this version of driver core, version 2.11.0 of Jackson Databind is what will be used. Below is the dependency tree output for the core module:
The vulnerable version of Jackson Databind (220.127.116.11 according to Maven Central here) is declared as an optional dependency for gremlin-shaded version 3.4.5. Unless your application explicitly declares version 18.104.22.168 of Databind, and does so ahead of the driver dependency, you won't get that version as the 2.11.0 version the driver already declares will supersede it.
The listed CVEs are all about "gadgets" which is essentially ways of instantiating classes from JSON, where the objects constructed could be malicious, if you are using Jackson Databind's JSON mapper functionality, which the driver does not use. There is some more info about how these exploits in general here: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062. So in most cases, even if the driver were using a vulnerable version of Databind, it still wouldn't be exploitable in the driver, as the mapping to/from JSON is not used in the driver.
Also, the CVEs listed mention specific gadgets that are in other libraries that the driver does not use (things like HikariConfig, JtaTransactionConfig, AnterosDBCPConfig, etc.). Again, even if the driver were using a vulnerable version of Databind, and if the driver were using JSON mapping, the driver still wouldn't be vulnerable as it doesn't try to use any of those classes.
All that said, I'm not sure how the security scan is being performed. It appears the scan is looking at every transitive dependency of every dependency the driver has, not simply the effective classpath of the application using the driver. If that is the case, the scan is being too aggressive and flagging issues that are not really present.
Closing this as I've hopefully explained why this isn't an issue for the driver.
Re-opening this ticket as my explanation was wrong. The gremlin-shaded artifact actually shades the vulnerable Jackson Databind library (deeper investigation done by . We will amend this ticket to get the right fix ASAP.