
Jackson-databind – remote code execution vulnerability - JensRantil
https://lists.debian.org/debian-security-announce/2019/msg00191.html
======
lol768
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.

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

~~~
cipherboy
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](https://news.ycombinator.com/item?id=21171746)

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

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

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

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

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

~~~
beardedwizard
You tried eua and still got false positives?

------
GlitchMr
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)

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

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

------
vesinisa
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...](https://blog.sonatype.com/jackson-databind-remote-code-execution)

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

~~~
lol768
>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-
databind/issues/2195)

[https://github.com/FasterXML/jackson-
docs/wiki/JacksonPolymo...](https://github.com/FasterXML/jackson-
docs/wiki/JacksonPolymorphicDeserialization)

~~~
vesinisa
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-...](https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-
is-what-you-need-to-know-54cd0d6e8062)

------
orf
This is one of the fixes: [https://github.com/FasterXML/jackson-
databind/commit/9593e16...](https://github.com/FasterXML/jackson-
databind/commit/9593e16cf5a3d289a9c584f7123639655de9ddac)

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

~~~
dtech
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-...](https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-
is-what-you-need-to-know-54cd0d6e8062)

------
twic
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-...](https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-
is-what-you-need-to-know-54cd0d6e8062)

The most recent relates to blocking yet another gadget:

[https://github.com/FasterXML/jackson-
databind/issues/2478](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.

------
based2
[https://github.com/FasterXML/jackson-
databind/issues/2410](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](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-...](https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-
is-what-you-need-to-know-54cd0d6e8062)

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

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

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

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

~~~
cipherboy
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...](https://bodhi.fedoraproject.org/updates/FEDORA-2019-b171554877)
F31 Bodhi:
[https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f...](https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f5f)

------
vs2
Jackson-databind is an enterprise virsus ...

