3

My project uses different versions of jackson library at a number of places, and a security scanner flagged that the binary is vulnerable to CVE-2018-14721. My reading of https://nvd.nist.gov/vuln/detail/CVE-2018-14721 is that the vulnerability is about deserialization of axis2-jaxws classes resulting in SSRF.

Is this CVE applicable if axis2 is not used in the project? Is this CVE applicable to jackson-mapper-lgpl:1.9.3?

Ajmal Ahammed
  • 31
  • 2

3 Answers3

2

I have the same reading as you about the fact that only the axis2-jaxws is concerned.

However, not using this module in your project could not be sufficient if you are using other parts of jackson whose make call to this vulnerable axis2-jaxws.

In order to be sure, you should inspect every part of jackson you are using, check their dependencies (if axis2-jaxws is in the list it's not good), check the dependencies of their dependencies (if axis2-jaxws is in the list it's not good), and so one.

At least, in your specific case, we could say that, as it is discouraged to use multiple version of the same software in a project, it is strongly recommended that you simply use the most recent one.

Sibwara
  • 1,316
  • 7
  • 19
  • My project is maven based, and as per `mvn dependency:tree`, axis does not show up anywhere. On the suggestion to avoid multiple versions of the same library, I don't have much control on them since they are added as transitive dependencies by other third-party libraries. – Ajmal Ahammed Aug 03 '20 at 10:42
1

I agree with Sibwara. Maintaining a bunch of different versions of Jackson in the same project is building in some technical debt and should be avoided. For this specific CVE, the effort to prove Jackson is not using axis2-jaxws somewhere may be greater than just upgrading all instances of Jackson to the latest version. And what about all the other CVEs associated with older versions of Jackson? CVE-2019-12384, CVE-2019-14379 etc.?

Just like with security patches for Operating Systems, you don't spend a lot of time wondering if the vulnerable part is used, you just do the patch.

mcgyver5
  • 6,807
  • 2
  • 24
  • 45
1

Looking at a random patch shows adding the axis class to a deny list (historically known as a 'blacklist'). Deny lists are bodges. It's not a case of having code that uses axis - it only matters whether the axis class is present (accessible by the relevant class loader instance). As with many vulnerabilities of this type, the reference to the 'helpful' class is in the untrusted data - i.e. controlled by the adversary.

General take away points:

  • Do not use deny lists, other than as a blatant hack.
  • Do not use any form of open-ended deserialisation (or more generally, non-static typing).
  • Allow lists (historically 'whitelists') are not very practical unless already redundant.
Tom Hawtin - tackline
  • 284
  • 2
  • 11