5 ms·

Jackson-databind – remote code execution vulnerability

43 points by JensRantil 7y ago

vs2 7y ago
Jackson-databind is an enterprise virsus ...
TicklishTiger 7y ago
How do you check if a machine is using jackson-databind?
- sheeshkebab 7y ago
  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 7y ago
    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 7y ago
      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-b171554877 https://bodhi.fedoraproject.org/updates/FEDORA-2019-b1715548... F31 Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f5f https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f...
GlitchMr 7y ago
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)
- deleted 7y ago
  [deleted]
- dtech 7y ago
  See their blogpost [1] for a detailed explanation and why this is required [1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
vesinisa 7y ago
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-execution 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.
- lol768 7y ago
  >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/JacksonPolymorphicDeserialization https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymo...
  - vesinisa 7y ago
    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-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
- Iv 7y ago
  Or just admit it will always be an unsafe operation. There are cases where you trust the source.
lol768 7y ago
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 7y ago
  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 7y ago
    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-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
    - TallGuyShort 7y ago
      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.
orf 7y ago
This is one of the fixes: https://github.com/FasterXML/jackson-databind/commit/9593e16cf5a3d289a9c584f7123639655de9ddac 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.
- dtech 7y ago
  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-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
twic 7y ago
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-here-is-what-you-need-to-know-54cd0d6e8062 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 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 7y ago
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-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-... # Safe Default Typing (safe Polymorphic Deserialization) https://medium.com/@cowtowncoder/jackson-2-10-features-cd880674d8a2 https://medium.com/@cowtowncoder/jackson-2-10-features-cd880...

43 points by JensRantil 7y ago

vs2 7y ago

Jackson-databind is an enterprise virsus ...

TicklishTiger 7y ago

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

sheeshkebab 7y ago
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 7y ago
  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 7y ago
    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-b171554877 https://bodhi.fedoraproject.org/updates/FEDORA-2019-b1715548... F31 Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f5f https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f...

GlitchMr 7y ago

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)

deleted 7y ago
[deleted]
dtech 7y ago
See their blogpost [1] for a detailed explanation and why this is required [1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

vesinisa 7y ago

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

lol768 7y ago
>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/JacksonPolymorphicDeserialization https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymo...
- vesinisa 7y ago
  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-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
Iv 7y ago
Or just admit it will always be an unsafe operation. There are cases where you trust the source.

lol768 7y ago

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

orf 7y ago

This is one of the fixes: https://github.com/FasterXML/jackson-databind/commit/9593e16cf5a3d289a9c584f7123639655de9ddac 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.

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

twic 7y ago

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-here-is-what-you-need-to-know-54cd0d6e8062 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 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 7y ago

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-here-is-what-you-need-to-know-54cd0d6e8062 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-... # Safe Default Typing (safe Polymorphic Deserialization) https://medium.com/@cowtowncoder/jackson-2-10-features-cd880674d8a2 https://medium.com/@cowtowncoder/jackson-2-10-features-cd880...