Indeed it does, Thanks again.
On Wednesday, May 8, 2019 at 7:59:16 PM UTC+1, Tatu Saloranta wrote: > > On Wed, May 8, 2019 at 2:13 AM Jack Higgins > <[email protected] <javascript:>> wrote: > > > > 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 ? > > 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 +- > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/9f8498f4-2975-4708-9f03-cdbd8b27bc3b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
