Hi @SSaha312872 (Community Member)​ ,

Starting with the September release of Veracode Static Analysis we've added support for reporting on potential unsafe deserialization with Jackson Databind through the ObjectMapper.readValue method.

As a number of recent CVEs show it is possible to use this library in a way that allows arbitrary code execution by an attacker:

* https://nvd.nist.gov/vuln/detail/CVE-2019-16942

* https://nvd.nist.gov/vuln/detail/CVE-2019-16943

* https://nvd.nist.gov/vuln/detail/CVE-2019-17267

Veracode Static Analysis currently reports any use of ObjectMapper.readValue that uses data from outside the application however this does not necessarily mean that this is automatically vulnerable to remote code execution.

The following blog by the Jackson maintainer has more information and is highly recommended: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 .

In short though, in order to be vulnerable you must have the following:

1. An attacker needs to be able to manipulate the JSON input. Please note that Veracode Static Analysis may not be able to see if this is coming from a trusted upstream API.
2. The destination being deserialized to should have a property that is typed with something like 'Object', 'Serializable', 'Comparable' or 'Clonable'. For example "public Object name;"
3. And this property should be exposed with:
   1. 'ObjectMapper.enableDefaultTyping()' (deprecated in v2.10.0).
   2. the annotation @JsonTypeInfo(use = Id.CLASS)
4. And Jackson Databind >= 2.10.0 should not be in use or the whitelisting capabilities of this new version should be disabled. See also: https://medium.com/@cowtowncoder/jackson-2-10-features-cd880674d8a2 .

We are investigating ways to be better able to detect 2, 3 and 4 but for how we recommend you manually verify this.

If, for example your serialisation destination does not rely on 'polymorphic typing' you might consider proposing a mitigation and having this mitigation reviewed by your security team (more information on this process here: https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/~p4MSKOS8F8X8h0KwFTKoQ ).

Alternatively to remediate this flaw (have Veracode Static Analysis automatically close this flaw) you can investigate using alternative JSON libraries, this StackOverflow post had a good overview: https://stackoverflow.com/a/31743324/4512 .

In your specific case I would recommend going through the following:

1. Is it feasible for me to switch to another way of deserializing JSON?
2. If not, I would highly recommend upgrading to version 2.10.
3. After upgrading please review how "converToJsonObject" was used, was it ever used with classes that have 'polymorphic type handling'? If so you may want to check the logs if this has not already been abused. If not, you may consider proposing a mitigation by design stating that you have upgraded to 2.10 and are not using 'polymorphic type handling'. Please feel free to link to this community post in the mitigation. Then reach out to your security team to have the proposal(s) reviewed.

Please let me know if you have any remaining questions or concerns.

Thank you,

Boy Baukema