Jackson-databind: Block yet another gadget type (jdom, CVE-2019-12814)

[cowtowncoder]

Similar to other polymorphic types with no limits, but for XXE with jdom2.jar, tracked as CVE-2019-12814.

See https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 for description of the general problem.

Fixed in:

• 2.9.10
• 2.8.11.4
• 2.7.9.6
• 2.6.7.3

[cowtowncoder]

Fixed in 2.7, 2.8, 2.9, 2.10 and master branches for likely release in 2.9.9.1 and 2.10.0.

[anthonymonori]

When can we expect a 2.9.9.1 release?

[volkert-fastned]

I appreciate the hard work being done by the jackson-databind developers, but 3 days later, I have to repeat @antalindisguise's question again: Why isn't 2.9.9.1 released yet? Those of us who use the OWASP Dependency Check plugin in our projects now have failing builds because of CVE-2019-12814, without a proper remedy. I really don't like adding a suppression for a legitimate security issue. 😕

[OrangeDog]

@volkert-fastned if it helps, you've had a legitimate security issue for ages already, you just didn't know about it until today. Plus, if you don't have JDOM then it would be a legitimate suppression,

[volkert-fastned]

@OrangeDog Thanks. I read it in the CVE description as well.

So when the following commands return no results, the project should be unaffected, correct?

# Maven project
mvn dependency:tree | grep -i jdom

# Gradle project
./gradlew dependencies | grep -i jdom

[EiriniGraonidou]

@OrangeDog Thanks. I read it in the CVE description as well.

So when the following commands return no results, the project should be unaffected, correct?

# Maven project
mvn dependency:tree | grep -i jdom

# Gradle project
./gradlew dependencies | grep -i jdom

Well you would also have to "enableDefaultTyping" (either globally or for a specific property :)

[mpbalmeida]

For me, the problem is that our pipeline checks for dependencies with known issues and abort the process if a problem is found. You can argue that the problem is in the previous versions, but if the problem is solved why not just release?

[OrangeDog]

@mpbalmeida in general you cannot expect every dependency to release a fix as soon as a vulnerability is known. If your pipeline relies on that, then you need to make changes.

[OrangeDog]

@volkert-fastned

So when the following commands return no results, the project should be unaffected

What's on the classpath when your code runs is not simply the list of project dependencies. You need to audit your systems and be aware of what's happening.

[mpbalmeida]

We can manually trigger to rebuild, but I thought the problem was already solved because there were no open issues in 2.9.9.1 milestone

[bdemers]

I don't know the details of how this issue was discovered or originally disclosed (insert grain of salt)
But IMHO, It would be nice to release the fix before disclosing the vuln.

[volkert-fastned]

@volkert-fastned

So when the following commands return no results, the project should be unaffected

What's on the classpath when your code runs is not simply the list of project dependencies. You need to audit your systems and be aware of what's happening.

In the specific case of CVE-2019-12814, one of the prerequisites for being vulnerable (kind of a weird way to put it, but you know what I mean) is "the service has JDOM 1.x or 2.x jar in the classpath". Source: https://nvd.nist.gov/vuln/detail/CVE-2019-12814

[volkert-fastned]

By the way, it's kind of odd how an XML dependency such as JDOM would trigger a JSON-related vulnerability.

[andr3w-hilton]

@volkert-fastned if it helps, you've had a legitimate security issue for ages already, you just didn't know about it until today. Plus, if you don't have JDOM then it would be a legitimate suppression,

It is worth noting that JDOM2 comes as a dependency within the latest version of Spring-Boot-Starter-Parent 2.1.6
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent/2.1.6.RELEASE
_(edited to reflect a mistake i made by saying spring-boot when I meant spring-boot-starter-parent)
Thanks @Benjamin Asbach for making me recheck and finding my mistake_

If you run the cmd:
mvn help:effective-pom -Doutput=effective.xml
and then search for JDOM you can see it's there at version 2.0.6

Really hoping version 2.9.9.1 is released soon, this is causing me head aches.

[volkert-fastned]

It is worth noting that JDOM2 comes as a dependency within the latest version of SpringBoot 2.1.6

If you run the cmd:
mvn help:effective-pom -Doutput=effective.xml
and then search for JDOM you can see it's there at version 2.0.6

Really hoping version 2.9.9.1 is released soon, this is causing me head aches.

Really??? I thought mvn dependency:tree also showed all transitive dependencies. Yet another thing you can't rely on. 😕

Thanks for sharing this method, @andr3w-hilton.

And again, not to be ungrateful to the developers, but what's holding up the 2.9.9.1 release right now? Is it undergoing a final rigorous code audit and/or pentest? Because in that case, I completely understand and support the current holdup.

[GedMarc]

@volkert-fastned @cowtowncoder has simply taken a break lol - nothing more nothing less.
Perhaps assist by having a PR ready for when he gets back?

[volkert-fastned]

Well, to be fair, everybody deserves a good vacation every now and then. 🙂

But I don't think any PRs are necessary anymore. The actual issues have already been resolved. It's just that we're still waiting for the 2.9.9.1 release that contains these fixes: https://github.com/FasterXML/jackson-databind/milestone/97

By the way, It's somewhat worrisome how such a crucial library like jackson-databind apparently has so few developers maintaining it, that the vacation of one person would block a release with an important security fix. One obviously can't blame any individual developers or maintainers for that. This is a problem that needs to be solved at an organizational level.

[GedMarc]

xD

Not really, usually all deploys are held monitored and approved by a single person?

There's a few maintainers hey, I know Tatu is getting ready for 2.10 and doing the min jdk8 impl, i'm doing the jpms impl, I know a few others are doing a few bits as well.
Also what organization do you believe is running this project? :)

Naw, the way it is now is correct, the single point for final approve and deployment definitely is correct. and yea I think he is allowed a break for as long as needed. Rather wait patiently and get a refreshed mind doing it. There also seems to be people complaining about dropping jdk 6 support (but 2.10 drops jdk 7 support), so I believe there's that consideration for 2.9.10 as well for some security fixes (although the jdk has more holes than any library), so there's a lot going on

[OrangeDog]

all deploys are held monitored and approved by a single person?

If (hopefully not) the one person who can do that gets hit by a car while on holiday, does that mean that there will never be another release of Jackson? There needs to be multiple people who can do it, both to deal with that situation, and with this one.

[OrangeDog]

I thought mvn dependency:tree also showed all transitive dependencies.

It does. @andr3w-hilton is mistaken and looking at the <dependencyManagement> section, not the <dependencies>.

[andr3w-hilton]

My mistake, I had a project that used a parent-pom for some dependencies (including JDOM within springboot 2.1.6). Which didn't show JDOM on the mvn dependency:tree output but did show on the effective-pom output.

Sorry for the confusion.

[asbachb]

Am I the only one wondering why the release should be 2.9.9.1 instead of 2.9.10?

[Shiva19908]

Fixed in 2.7, 2.8, 2.9, 2.10 and master branches for likely release in 2.9.9.1 and 2.10.0.

Hello,
Does this mean that the CVE-2019-12814 is fixed in jackson-databind version 2.9.8?
Thanks

[OrangeDog]

@Shiva19908 no, it means it will be fixed in 2.9.9.1 and 2.10.0.

[cowtowncoder]

@asbachb 2.9.9.1 vs 2.9.10 comes down to whether I think spending lots of time (full 2.9.10) to get every component is warranted vs spending less time to release only jackson-databind.

I am back for couple of days now, but flying out again in 2 days. I may have time to release databind 2.9.9.1 for everyone desperate to get that version.

[joelschopp]

A rose by any other name...
Happy to have a release that fixes this CVE whatever the number.

[cowtowncoder]

Release 2.9.9.1 in-progress.

[a1dutch]

2.9.9.1 is in Maven Central is this good to use?

[andr3w-hilton]

I have just used it and it worked perfectly! @cowtowncoder thanks for getting this released before you head off again. Really appreciated. Have a great break away.

[phil105]

@cowtowncoder is there a possibility to update jackson-dataformat-xml as well?

[cowtowncoder]

@andr3w-hilton you are welcome!

@phil105 only jackson-databind released: point of micro-patches is that only individual components released; full set (which will include xml module) will be part of 2.9.10

[shemnon]

Has any though been put into providing hooks to add names to the DEFAULT_NO_DESER_CLASS_NAMES? Either through a system property, environmental variable, or some other externally configurable value? This would allow for a "field patch" that would provide the same style of fix that users can deploy while waiting for the release cycle to finish.

[lol768]

Is it really sustainable to keep blacklisting new gadgets that may or may not lie on the classpath at runtime? Also, why is this considered to be something that needs to be mitigated here, in this library?

The real security issue lies within the Default Typing feature in general - when used with user input - no?

I'm somewhat tired of Snyk about these CVEs, but don't know enough about the historical context/background of this feature to understand this issue properly.

---

After some reading: Your docs acknowledge it's dumb to use default typing with user content! https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization

Hence, the behaviour works exactly as expected. Why are you trying to maintain a blacklist at all? It's a pointless, hopeless endeavour - and none of these CVEs are actually valid vulnerabilities in jackson-databind at all. The _calling application_ that's using default typing with user content is the problem and CVEs should be filed against software that is doing this rather than creating noise upstream for something that should _not_ be considered upstream's problem. What on earth is the CNA thinking, assigning all of these CVEs?

[cowtowncoder]

@lol768 I agree with many of your points, and have written:

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062

to explain the situation, and based and A LOT of feedback, commentary, suggestions, worked on

2195

to try to provide a solution that shows the way forward (and specifically allows convenient allow-listing, deprecates easy "allow anything") before 3.0 is released (which will remove deprecated "allow-anything" criteria).
It would then also be possible to offload these "unsafe class" checks for those users who would still want to rely on that approach (if any), and remove need that databind provides such lists and updates.

Personally I strongly dislike the way CVE system works, as well, as there is only black/white way that suggests that a version of a library is unsafe, regardless of whether it is just an option users can use. In Jackson case default usage does not even allow these vulnerabilities (as Default Typing is opt-in). But... I have very little power over Big Security, business based on selling fear. :-/

So. Addition of types in block lists is something driven by vuln reports and expectations by many users that there is something to "turn off those nasty warnings".

[lol768]

Excellent write-up @cowtowncoder - it covers in depth all of the various conditions that need to be met for exploitation. #2195 looks like a sensible way forward to tackle this.

But... I have very little power over Big Security, business based on selling fear. :-/

So. Addition of types in block lists is something driven by vuln reports and expectations by many users that there is something to "turn off those nasty warnings".

Indeed, the incentives here are all messed up. Vuln. reporters get a shiny new CVE for their CV, Snyk get more red scary High Severity!! CVEs to alert customers about in order to show their service is working. The developers who have to maintain this block-list? Blue team who have to check all of these reports? Developers who have to deal with spurious reports about their projects which don't even use default typing and aren't vulnerable? Screw those guys.

This is what happens when security becomes a compliance checkbox exercise.

Personally I strongly dislike the way CVE system works, as well, as there is only black/white way that suggests that a version of a library is unsafe, regardless of whether it is just an option users can use

Honestly, I don't think these CVEs should've even been issued. Certainly not at the CVSS they've been assigned, anyway. There are just too many pre-requisites that need to be in place for them to actually be exploited.

It's like raising a CVE with MySQL because you can make a project with it that is vulnerable to SQL injection.