Jackson-Databind 2.10 / 3.x Vulnerabilities (CVE's) Fix

[Jack Higgins]

Hi @cowtowncoder,

Apologies if I'm repeating an old question here. 

I have a service which is using jackson-databind and I'm aware that in version 2.9.8 the issue regarding CVE vulnerabilities related to jackson-databind and default typing have been somewhat resolved using a blacklisting approach. 

It now looks like there will be a new fix added to upcoming 2.10 / 3.x release and I was wondering if there is any blog which describes this fix and how its more secure compared to 2.9.8 ? 

Also If the fix will be included in 2.10, is there a rough estimate as to its release date ?

Thanks again for your help. 

[Tatu Saloranta]

Your summary is spot on. The work itself is for this issue:

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

and included as about the only remaining must-have thing for 2.10, as per:

https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress

I am maybe 80% done with the initial implementation, and was hoping to
announce something more once it is complete (what is missing is simply
the default/basic implementation of new PolymorphicTypeValidator for
users to use). This could be a blog post, linked to from an
announcement on jackson-dev.
Once this is done I am planning to release 2.10.0.pr1 to give everyone
chance to see how this would work -- it is possible some changes would
be needed before finalizing this new extension point.

The basic idea with `PolymorphicTypeValidator` is along these lines:

1. There are 2 configured instances to use: one for default typing
(passed as a new argument -- old methods deprecated, pass permissive
instance), another for annotation approach (globally configured, with
permissive default)
2. Validator gets called at 2 points:
(a) When a polymorphic property definition is handled, to see if
base type is allowed or not (to, for example, prevent use of
`java.lang.Object` as base type); or, as optimization, all subtypes of
given base type are automatically allowed (when user controls that
type)
(b) If (a) returns "can't determine", each subtype classname is
separately verified upon encountering for the first time, and may be
allowed or denied.
3. There will be an out-of-the-box implementation that allows simple
allow-listing of acceptable types, for users to use (but no
block-listing -- users can implement ones should they want to, of
course, but we want to discourage that)

With 2.10, then, improvement in security depends on adoption of this
new functionality.
With 3.0, defaulting will be removed (for default typing), or made
strict (so annotation-based approach will, by default, not allow known
risky approaches -- details TBD).

If there will be 2.11, we may -- as a community -- decide if we want
to make an exception to following SemVer with respect to
now-deprecated "enableDefaultTyping()" methods and/or chance default
validator to be less permissive. But this is a bigger discussion and I
think it is absolutely necessary to first enable opt-in for new
approach in 2.10, and advocate for its use.

I realize that it may get bit tricky for frameworks that would ideally
like to support wide range of Jackson versions, but still want to use
new secure approach to classname-based polymorphic deserialization.

Does this answer your question?

-+ Tatu +-

[Jack Higgins]

Indeed it does,

Thanks again. 

[Andi Egloff]

Hi Tatu, 

As background to my questions, I'm guessing we're not the only ones that have been forced to keep up with the arms race of steady flow of CVEs and fixes in our products; even if it isn't actually exploitable in the way we use it, customers will not accept libraries to be present with known potential exploits. 

As such I would like to verify I understand the current plan to address this. Is it correct to read this as:

2.10 will likely not slow the flow of CVEs, as it keeps permissive defaults and requires opt-in?

3.0 you do expect to stop this particular avenue for flow of CVEs, as it removes permissive defaults?

What is a time frame now for a version that fundamentally addresses this flow of CVEs? Might it be possible to have a short term plan just to address this issue?

[Tatu Saloranta]

On Mon, Jul 29, 2019 at 3:22 PM Andi Egloff <andi....@gmail.com> wrote:

Hi Tatu, 

As background to my questions, I'm guessing we're not the only ones that have been forced to keep up with the arms race of steady flow of CVEs and fixes in our products; even if it isn't actually exploitable in the way we use it, customers will not accept libraries to be present with known potential exploits. 

Yes.

 

As such I would like to verify I understand the current plan to address this. Is it correct to read this as:

2.10 will likely not slow the flow of CVEs, as it keeps permissive defaults and requires opt-in?

Yes and no.

I think it as unfortunate that there is the perception of permissive defaults -- Jackson does not enabled default typing by default, so none of CVEs is available with default settings.

But it is true that behavior of existing enable-methods does not change, nor do I see it trying to change them practical. At least not with 2.10.

Case could be made that with introduction of new methods (which require specification of a `PolymorphicTypeValidator` and provide only opt-in implementations), it would be possible to change defaults -- or, even (violating SemVer) remove now-deprecated defaulting methods in 2.11.

Alternatively I could also make the case that as long as existing permissive default-typing-enabling-methods are Deprecated -- which they will be in 2.10 -- CVEs would only be labelled as applying to 2.9.x and earlier versions.

I could use help in formulating reasoning here but it seems to me like potential way to remove flow of CVEs that force upgrades.

 

3.0 you do expect to stop this particular avenue for flow of CVEs, as it removes permissive defaults?

3.0 does not have methods that would allow easy enabling of permissive polymorphic subtypes, correct.

 

What is a time frame now for a version that fundamentally addresses this flow of CVEs? Might it be possible to have a short term plan just to address this issue?

I am open to suggestions, but will have to balance removal of functionality / change of default behavior with ensuing breakage of many legit use cases (meaning bunch of unhappy users who are annoyed by "simple upgrade" breaking their systems).

Right now arguing that use of deprecated methods to open up unsafe processing does not fall under "default settings" seems like the best way to go; and that would mark 2.10 as solution to this particular stream of issues.

WDYT?

-+ Tatu +-

 

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/1b3da01f-76d0-4fb4-815d-be6fc39a9c83%40googlegroups.com.

[Andi Egloff]

Thanks for the thorough answer.

On Tuesday, July 30, 2019 at 1:47:18 AM UTC+2, Tatu Saloranta wrote:

On Mon, Jul 29, 2019 at 3:22 PM Andi Egloff <andi....@gmail.com> wrote:

Hi Tatu, 

As background to my questions, I'm guessing we're not the only ones that have been forced to keep up with the arms race of steady flow of CVEs and fixes in our products; even if it isn't actually exploitable in the way we use it, customers will not accept libraries to be present with known potential exploits. 

Yes.

 

As such I would like to verify I understand the current plan to address this. Is it correct to read this as:

2.10 will likely not slow the flow of CVEs, as it keeps permissive defaults and requires opt-in?

Yes and no.

I think it as unfortunate that there is the perception of permissive defaults -- Jackson does not enabled default typing by default, so none of CVEs is available with default settings.

But it is true that behavior of existing enable-methods does not change, nor do I see it trying to change them practical. At least not with 2.10.

Case could be made that with introduction of new methods (which require specification of a `PolymorphicTypeValidator` and provide only opt-in implementations), it would be possible to change defaults -- or, even (violating SemVer) remove now-deprecated defaulting methods in 2.11.

Alternatively I could also make the case that as long as existing permissive default-typing-enabling-methods are Deprecated -- which they will be in 2.10 -- CVEs would only be labelled as applying to 2.9.x and earlier versions.

I could use help in formulating reasoning here but it seems to me like potential way to remove flow of CVEs that force upgrades.

I've run this by the security teams. It seems to be a reasonable approach. Hopefully it will be considered valid by security researchers.

In case it turns out it does not get accepted as valid, one other option (which I'm guessing you have considered too) - and which would not violate SemVer - would be to release a version of 2.10 without the deprecated methods as a new major release, and then relabel the current 3.0 as something else. I realize this would have implications on messaging and renaming work, but it would seem a clean way to address it. If rev-ing a major version is not feasible, but SemVer should not be violated, another approach (but less clean) would be to release a version of 2.x without the deprecated methods under a different artifactId.

To unsubscribe from this group and stop receiving emails from it, send an email to jackso...@googlegroups.com.