Jackson Deserialization Vulnerability
On July 29th, 2019 a high severity Deserialization of Untrusted Data vulnerability ( CVE-2019-14379, CVE-2019-14439) affecting all versions of com.fasterxml.jackson.core:jackson-databind up to 18.104.22.168 was published.
For those of you who use Spring Boot, note that the current release (2.1.7) depends on the older vulnerable jackson-databind 2.9.9 package.
We have already updated this in our database and the maintainers of jackson-databind package created a fix. If you use Snyk, you are already informed about this vulnerability. The team maintaining the jackson-databind package already did an amazing job by creating a new version (22.214.171.124) that doesn’t contain this vulnerability. The Snyk scanner will provide this version as remediation advice so you will not be affected anymore.
About the vulnerability
This is not the first time that the jackson-databind package was subject to a Deserialization of Untrusted Data vulnerability. In fact, there are more than a dozen of these vulnerabilities known and disclosed since 2018, not to mention that almost all of these vulnerabilities are considered to be highly severe.
The main goal of the library is to serialize Java objects into JSON and the other way around. The problem lies in deserializing JSON back to Java objects. When a poorly written Java application has the ability to deserialize a JSON string from an untrusted source, a hacker can use this, for instance, to launch a remote code execution.
If polymorphic typing is activated for Jackson, an attacker can use a gadget to launch their attack when they control the JSON input. A gadget is a class or function that has already existing executable code present in the vulnerable process. This existing executable code can be reused for malicious purposes.
For this specific vulnerability, a gadget from Ehcache could be misused when default typing in Jackson is enabled. This was quickly solved by the maintainers of jackson-databind by adding the specific gadget to the already existing blacklist. Version 126.96.36.199 was released and does not contain this vulnerability anymore.
At the time of writing this blog, the latest release version of Spring Boot is 2.1.7. This version has a dependency on the older jackson-databind 2.9.9 package.
This means that if you build a new Spring-Boot application using the Sping Boot Initialzr you will definitely have a vulnerable jackson-databind version included.
While a new version of Spring Boot, or spring-boot-starter-data-rest is not yet released, we can switch out the jackson-databind versions. One way is to exclude the individual package as shown in the Maven example below:
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-rest</artifactId> <exclusions> <exclusion> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>188.8.131.52</version> </dependency> … </dependencies>
A better solution is to set the Maven property to the appropriate version. This way Spring Boot imports the fixed Jackson BOM (Bill of Materials) that handles all individual Jackson dependencies. In a Gradle project, a similar thing can be set in the gradle.properties file. For more information on Maven BOM and why this is important for Spring Boot, please read the blog: “What’s a Bill Of Material BOM File“
<properties> <jackson.version>184.108.40.20690807</jackson.version> </properties>
Libraries like jackson-databind are in many cases an indirect dependency that will be part of a larger framework. Therefore it is wise to scan your applications for known vulnerabilities for particularly these indirect dependencies. By doing this on a regular basis you know is you are vulnerable and might be able to fix these issues accordingly.
SPRING CLEAN YOUR APPLICATION WITH SNYK