-
Bug
-
Resolution: Done
-
Medium
-
Amsterdam Release, Beijing Release, Casablanca Release
-
None
Inventory has a transitive dependency upon jackson-databind from dropwizard core. There is no non-vulnerable version of this library so updating jackson-databind does not address this security issue.
We need clarity on the importance of this and how to proceed forward.
Issue CVE-2017-7525 Source National Vulnerability Database Severity CVE CVSS 3.0: 9.8 Weakness CVE CWE: 502 Description from CVE A deserialization flaw was discovered in the jackson-databind, versions before 2.6.7.1, 2.7.9.1 and 2.8.9, which could allow an unauthenticated user to perform code execution by sending the maliciously crafted input to the readValue method of the ObjectMapper. Explanation jackson-databind is vulnerable to Remote Code Execution (RCE). The createBeanDeserializer() function in the BeanDeserializerFactory class allows untrusted Java objects to be deserialized. A remote attacker can exploit this by uploading a malicious serialized object that will result in RCE if the application attempts to deserialize it. Detection The application is vulnerable by using this component, when default typing is enabled. Note: Spring Security has provided their own fix for this vulnerability (CVE-2017-4995). If this component is being used as part of Spring Security, then you are not vulnerable if you are running Spring Security 4.2.3.RELEASE or greater for 4.x or Spring Security 5.0.0.M2 or greater for 5.x. Recommendation There is no non vulnerable version of this component. Despite there being a fix provided by Jackson, it uses a black-list approach. If there is another class not black-listed which performs deserialization on the classpath, then this may lead to code execution. We recommend investigating alternative components or a potential mitigating control. Workaround: Do not use the default typing. Instead you will need to implement your own. It is also possible to customize global defaulting, using ObjectMapper.setDefaultTyping(…) – you just have to implement your own TypeResolverBuilder (which is not very difficult); and by doing so, can actually configure all aspects of type information. Builder itself is just a short-cut for building actual handlers. Reference: https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization Examples of implementing your own typing can be found by looking at Spring Security's fix or this Stack Overflow article. Categories Data Root Cause jackson-databind-2.8.7.jar <= BeanDeserializerFactory.class : [2.8.0.rc1, 2.8.8.1) Advisories Project: https://github.com/FasterXML/jackson-databind/issues/1599 Third Party: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7525