Jackson-databind – remote code execution vulnerability | Hacker News Reader

Jackson-databind – remote code execution vulnerability

lists.debian.org

43 pointsJensRantil29 comments

These reports are a a waste of everyone's time. There are 10s of completely meaningless CVEs being issued for each new deserialization gadget that someone finds and gets added to a blacklist designed to protect a known-unsafe use-case (deserializing user input whilst defaultTyping is enabled).

They're not general vulnerabilities in the library. They surface when people use a documented-dangerous function in a stupid way.

Its aggravating because then internal security flags pick it up and create "upgrade this lib" busywork for every team.

Obviously this stuff (security disclosure) isn't easy but with such a pervasive library near monthly findings is a growing chore.

The correct response is to audit how you use it, especially what other libraries you have on the classpath. Per another comment on this submission [0], its unlikely that you've satisfied all the requirements for exploiting these CVEs. If you don't satisfy those preconditions, there's not much benefit in upgrading.

Additionally, 2.10 deprecates the unsafe behavior and introduces a new, safer alternative. See the blog post for more information there. [1] That might be a valid reason to spend time upgrading.

Obviously, if you're actually affected, then yes, upgrading or backporting patches is a good idea.

[0]: https://news.ycombinator.com/item?id=21171746

[1]: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

The problem is when you have customers who have internal no-CVE policies and a business-person looking at fortify instead of an engineer looking at the technology. Then they insist on special releases every month because Jackson has another CVE, and if you don't do it, their manager talks to your manager.

Even if you have the technologist, it's just too much work and it's soul breaking to go over every CVE, try to understand if the CVE is a real vulnerability or not and what it is about. They don't bother most of the time to explain what is the issue or what's the fix.

>They don't bother most of the time to explain what is the issue or what's the fix.

This - the vulnerability descriptions are usually incredibly poor. Snyk are bad at this too. What's particularly infuriating is when the descriptions tell you what a generic e.g. XSS or Java deserialisation vulnerability is. It's so incredibly patronising and doesn't tell you anything at all about the _specifics_ of the problem.

If you're really lucky you'll be able to find the patch that fixes the CVE on GitHub (often the commit messages are deliberately vague - I guess the devs think it'll be exploited less this way?) and then you can try to reverse engineer what the actual problem was and what you'd need to be to be exploitable.

And honestly, I’m not sure the businesspeople have it wrong here. Maybe I can guarantee that there’s no real issue in our current build; how do I know that nobody will ever change things in a way that exposes the vulnerability? What’s the control against a lazy or bad engineer saying “this other CVE can be ignored because I don’t personally see how to exploit it”?

They aren’t wrong. First you have a regulatory landscape that isn’t going to evaluate every CVE and every implementation so if you work in a regulated sector you get no CVE over X policy by default.

Second for a large enterprise with a lot of developed in house applications it’s impossible to validate every implementation and use case; so the default policy is updated or file for an exception in the exception process is upto the application owner in the business to make an argument to the security team why it’s not applicable.

No CVE policy is actually the smart way of doing things because it does moves the load form your security team which will be understaffed compared to the development staff (doesn’t matter if it’s in house or not) and they have better things to focus on than going over SCA or Vuln scanning CVE reports.

Have to agree with above comment - this is where snyk and whitesource are trying to stand out with usage analysis to tell you if you are truly vulnerable. The load is too high on both sides for humans.

My experience is that whitesource still has some way to go...

Someone who can solve this problem effectively could make some real money.

You tried eua and still got false positives?

Yes, this is a separate issue. jackson-databind is a XML/JSON parser so I was presuming a web stack here and that your customer wouldn't necessarily know what your backend was. Which also means that it is up to you to secure it properly, which has its own risk.

I'd just point out that accepting any customer's policy as something you implicitly agree to support is inherently risky without an adequate contract between the relevant parties. Presumably, you've signed a contract with the customer, and if they have a no-CVE policy, there's SLAs that you can point to that say what is and isn't covered, and by what date. So it is just the price of doing business and both parties know that this'll impact the delivery of other features, bug fixes, &c. Otherwise, your business-people aren't doing a great job of covering the costs of doing business with said customer... :)

Without much better developer tooling, we'll always be trying to catch up with the people who find vulnerabilities. People aren't perfect. Tools aren't perfect either. But they can complement each other nicely and currently most projects err on the side of "too little" rather than "too much" tooling.

The biggest problem is; jackson is not just my dependency, but a dependency of my dependencies. And those packages are not heavily managed enterprise things....

So it's an intense cycle.

A great step might be for libraries to note when their implementation of a package is safe.

The CVE database can be quite problematic for libraries. CVEs get registered according to some 'worst case' impact criteria. This means that more often than not, you the alerts go off for 'using the library in a stupid way' or 'using the library in an exotic/unusual way'. Often - not in this case - CVE descriptions are also poorly written, making it extremely difficult what kind of library use is the prerequisite for your product to be vulnerable.

Stuff like this warrants a followup, but you have to have a good option in your vulnerability management to accept a vulnerable dependency (especially if - unlike this case - the upgrade path is not available or requires extensive other upgrades). In any case, casual high-rated CVEs for library edge cases like this contribute a lot to "alarm fatigue".

Despite the CVE database being problematic for libraries, there's no real alternative for answering the question "do my dependencies have security problems?", so you've got to accomodate.

Those 6 vulnerabilities occur in a very specific situation (all of those must be true):

1. JSON content is sent by an untrusted client

2. Must have one of those libraries in classpath: Logback, HikariCP, commons-dbcp, P6Spy

3. Default typing must be enabled with enableDefaultTyping (very insecure, if your program has this, it's insecure even after this patch)

4. There must be a property with permissive type (such as Object, Serializable, Comparable, Cloneable, and so on)

See their blogpost [1] for a detailed explanation and why this is required

[1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

This seems to be a yet another manifestation of the same underlying issue that has marred this library since 2013:

https://blog.sonatype.com/jackson-databind-remote-code-execu...

The only reliable fix is surely stopping serialization of arbitrary classes by not using or auditting any use of the DefaultTyping feature.

>it is apparently on by default

Curious as to what makes you think this - I was under the impression you needed to explicitly call `enableDefaultTyping` to get this unsafe behaviour. The wiki page explicitly tells you not to do this with untrusted input and the method is deprecated in the latest versions of the library.

https://github.com/FasterXML/jackson-databind/issues/2195

https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymo...

From the blog I linked. They might have meant the feature was on by default in 2013. I edited that part away.

Here is a much better blog by the library author themself: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

Or just admit it will always be an unsafe operation. There are cases where you trust the source.

This is one of the fixes: https://github.com/FasterXML/jackson-databind/commit/9593e16...

It seems like it's a blacklist of types to not automatically de-serialize? If so, that's.... not good.

It's not. Jackson has been aware of that for some time. Initially it was hoped a blacklist would be good enough, but it wasn't. In the latest 2.10 version, the unsafe way is deprecated and an alternative.

It must be noted that the vast majority of Jackson use cases is not affected, you need to enable an optional feature that has been known to be unsafe for years [1]

[1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

The email has a list of CVEs. Some are related to quite old bugs, as described here:

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

The most recent relates to blocking yet another gadget:

https://github.com/FasterXML/jackson-databind/issues/2478

As another commenter mentions, this whole set of issues is only a problem if you call enableDefaultTyping during setup, and then deserialise data from untrusted sources. Doubtless, there are people doing this. But don't.

https://github.com/FasterXML/jackson-databind/issues/2410 Block one more gadget type (HikariCP, CVE-2019-14540)

https://github.com/FasterXML/jackson-databind/issues/2478 Block two more gadget types (commons-dbcp, p6spy, CVE-2019-16942 / CVE-2019-16943)

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

# Safe Default Typing (safe Polymorphic Deserialization) https://medium.com/@cowtowncoder/jackson-2-10-features-cd880...

How do you check if a machine is using jackson-databind?

You can unzip and look inside war files web-inf/lib (assuming it was packed with version number in file name) or you’d need to compare signatures of compiled classes packed into a jar file.

In other words, it’s quite difficult to do without running some scanning process designed to look for this library, and for specific versions of it that are vulnerable.

Not arguing, but since this news article is a specific link to the Debian Security tracker - the package is `libjackson2-databind-java` on Debian, presumably similar on others. If it was installed via package manager, `dpkg -l | grep jackson`, `rpm -qa | grep jackson` or similar on most Linux to possibly find it. I agree though that it's common for libraries like this to end up inside warballs.

jackson-databind is the name of the package on Fedora and on RHEL. We addressed this issue last week by updating to 2.10, though I think F30 and F31 updates still needs karma [0].

The other jackson packages are mostly Java package hierarchy that don't affect this CVE (jackson-core, jackson-bom, jackson-parent, and jackson-annotations -- but we've also updated all of these to 2.10 on F30+).

So:

    rpm -qa | grep jackson-databind

To the GGP:

As noted by other commenters just having the package isn't sufficient. You need a number of other libraries (most of which aren't shipped with Fedora, none of which are shipped on RHEL) on the classpath of the running JVM.

If you're not running any Java code, you're definitely not affected. If you're using any code distributed through the official channels, it is very unlikely that you're affected. You'll probably only be affected if you're using third-party projects. Which as always, are run at your own risk. :)

[0]: Source: co-maintainer of the package via the Fedora Stewardship SIG.

F30 Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b1715548... F31 Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f...

Jackson-databind is an enterprise virsus ...

Reply on news.ycombinator.com