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

When can we expect a 2.9.9.1 release?

@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.

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

Release 2.9.9.1 in-progress.

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.

@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”.

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.

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?

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.

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

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. 😕

@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

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

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>.

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.

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

@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.

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?

@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,

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.

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

2.9.9.1 is in Maven Central is this good to use?

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.