Jackson-databind: Block more classes from polymorphic deserialization (CVE-2018-14718 - CVE-2018-14721)

[cowtowncoder]

This issue covers following CVEs related to polymorphic deserialization, gadgets:

• CVE-2018-14718: RCE with slf4j-ext jar
• CVE-2018-14719: RCE with blaze-ds-opt, -core jars
• CVE-2018-14720: exfiltration/XXE with only JDK classes (some JDK versions)
• CVE-2018-14721: exfiltration/SSRF with axis2-jaxws

Original vulnerability discoverer:
吴桂雄 Wuguixiong

---

Fixed in:

• 2.9.7 and later
• 2.8.11.3
• 2.7.9.5
• 2.6.7.3

[bbossola]

When is the release of 2.8.11.3, with this fix, planned?

[bbossola]

bump :)

[cowtowncoder]

@bbossola I don't know. Question here is whether I'd release it now, or wait for another 4 classes that I know need to be blocked. Given there are 100+ dependencies for 2.8.11.2 there does seem to be demand for patches (which is sort of positive surprise).

[cowtowncoder]

Fix released on 23-Nov-2018, in:

• 2.7.9.5 (micro-patch of jackson-databind)
• 2.8.11.3 (micro-patch of jackson-databind, plus jackson-bom version 2.8.11.20181123 )

and will be included in 2.9.8 as soon as that gets released (full release along with other fixes)

[cedricdangremont]

@cowtowncoder.
when checking the archive for 2.6.7.2, I can see the content of the commit 87d29af25e82a249ea15858e2d4ecbf64091db44 which fixes the issue. Anyways, when I check the next releases (2.7.9.5, 2.8.11.3, 2.9.8), I don't find the associated code. In these versions the complete static initializer part containing the fix is missing.
Are these versions really fixed?
Thanks in advance.

[cedricdangremont]

@cowtowncoder please forget about my previous question, I have finally found out that the fix in the later releases was impacting another file. Please apologize.

Thanks
Cedric

[cowtowncoder]

@cedricdangremont no need to apologize, tracking this is not as easy as it should be. Glad you figured it out.

[eyecats]

@cowtowncoder - 2.8.11.3 has now been flagged for the same vulnerabilities as were fixed in this ticket:

• CVE-2018-14721
• CVE-2018-14720
• CVE-2018-14719
• CVE-2018-14718

Do you have details / information on a possible 2.8.11.4 micro-patch? (let me know if I should follow a process for reporting this or if it's already somewhere else - I might have missed it!)

Talk about whack-a-mole on these class blocks! :)

[cowtowncoder]

@eyecats These CVEs were fixed in 2.8.11.3, as per my comments above.

At this point I will most likely stop doing more merging of fixes to 2.8, including security patches so it is good to start thinking of upgrading.

[eyecats]

Hi @cowtowncoder - for some reason 2.8.11.3 was just added to the CPE list for each of these CVEs - just added yesterday (or at least our maven dependency-check plugin started picking it up yesterday).

I do agree you fixed - not sure why it's popping up in the CPEs now! Do you think these are just false positives?:

• https://nvd.nist.gov/vuln/detail/CVE-2018-14718/cpes?expandCpeRanges=true
• https://nvd.nist.gov/vuln/detail/CVE-2018-14719/cpes?expandCpeRanges=true
• https://nvd.nist.gov/vuln/detail/CVE-2018-14720/cpes?expandCpeRanges=true
• https://nvd.nist.gov/vuln/detail/CVE-2018-14721/cpes?expandCpeRanges=true

All CVEs for 2.8.11.3: https://nvd.nist.gov/vuln/search/results?form_type=Advanced&cves=on&cpe_version=cpe%3a%2fa%3afasterxml%3ajackson-databind%3a2.8.11.3

But, you're right, we'll start looking into upgrading! It's just harder for some of our applications :).

[cowtowncoder]

@eyecats Probably someone just read "before 2.9.8" to mean literally all versions, and is not familiar with the concept of multiple open release branches or something.

To me CVE system is much more hassle than value at this point: not only is there no concept of "MAY apply depending on your setting/usage" but also there is no useful way to manage or set versions after the fact (or maybe there is and I just have no resources to learn how to manage them -- or actual time to do that if I did). In this case I had an idea of version number for fixed-in, wrt 2.9, but in general fixed-in can only be known in hindsight, long after initial submission.
If anyone wants to submit additional information feel free to.

Worse, there are so many new tools that are being pushed in name of security that are based on flawed data, leading to unnecessary work. I realize that tooling would be useful if it reduced cognitive load, but unfortunately often they seem to over-simplify things into useless category... "as simple as possible but no simpler" as mr. Einstein stated it.
What a huge time sink, for absolutely no value for maintainers.

Anyway: I can't offer more information than to say that those 4 CVEs (... that I filed initially...)