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? On Wednesday, May 8, 2019 at 8:59:16 PM UTC+2, Tatu Saloranta wrote: > > On Wed, May 8, 2019 at 2:13 AM Jack Higgins > <therealja...@gmail.com <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 jackson-user+unsubscr...@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.
