Jackson-databind: Jackson Deserializer security vulnerability via default typing (CVE-2017-7525)

[ayound]

I have send email to [email protected]

[cowtowncoder]

I have received this and am investigating possible patch. Problem is quite specific, but some aspects are more general.

[cowtowncoder]

Fixed in 2.7, 2.8 and master (to the best of my knowledge): will be in 2.8.9 and 2.7.9.1, as well as 2.9.0.pr3.

[Viyond]

nice~

[ayound]

when do you want to release 2.7.10,2.8.9 and 2.9.0.pr3?

[JoyChou93]

when do you want to release 2.7.10,2.8.9 and 2.9.0.pr3?

[OneSourceCat]

I don't think blacklist is a good mechanism to prevent this issue, because there are other Java Deserialized Gadgets or ClassLoaders can arise this problem including com.sun.org.apache.xalan which is in your list.

[ayound]

I suggest you to use black list like this

"^bsh[.].", "^com[.]google[.]inject[.].", "^com[.]mchange[.]v2[.]c3p0[.].", "^com[.]sun[.]jndi[.].", "^com[.]sun[.]corba[.].", "^com[.]sun[.]javafx[.].", "^com[.]sun[.]org[.]apache[.]regex[.]internal[.].", "^java[.]awt[.].", "^java[.]rmi[.].", "^javax[.]management[.].", "^javax[.]naming[.].", "^javax[.]script[.].", "^javax[.]swing[.].", "^org[.]apache[.]commons[.]beanutils[.].", "^org[.]apache[.]commons[.]collections[.]functors[.].", "^org[.]apache[.]myfaces[.].", "^org[.]apache[.]wicket[.].", ".org[.]apache[.]xalan.", "^org[.]codehaus[.]groovy[.]runtime[.].", "^org[.]hibernate[.].", "^org[.]python[.].", "^org[.]springframework..", "^sun[.]rmi[.].", "^javax[.]imageio[.].*", "^java[.]util[.]ServiceLoader$", "^java[.]net[.]URLClassLoader$”

[channingwen]

hello, everybody, I wait for new version, where can I get the version release 2.7.10,2.8.9 and 2.9.0.pr3?

[maluguos]

@cowtowncoder
When 2.8.9 will be released? I can't find it in mvn repo or git release...

[taisenki]

When 2.8.9 will be released? I wait for new version...

[cowtowncoder]

@maluguos I do not release new version for every single bug fix. Have a look at release schedule:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.7

New version is unlikely to be released within next couple of weeks. Same goes for 2.8.9.
If a new version is needed sooner, you will need to use a local snapshot build.

[kuaike]

waiting for version 2.8.9 release...

[cowtowncoder]

@ayound I appreciate the list, but to be honest I think that restriction within core databind need to be focused on demonstratable security concerns. There are many types that could potentially be problematic, but I would hesitate to include very wide limits on, say, org. springframework, since there are utility types that may well be already in use by some users.
For 2.8 I did include a few types as per:

https://github.com/kantega/notsoserial

so I am not against extending the list, but at this point prefer keeping static blacklist to minimum.

[cowtowncoder]

Everyone: I did do mvn deploy for 2.8 branches, so snapshots via Sonatype snapshot repository (for 2.8.9-SNAPSHOT) should have initial protection for vulnerabilities indicated.

Perhaps more importantly, I just pushed micro-patch 2.7.9.1 of jackson-databind: it should be available soon via Maven Central. I decided to do this because it is not clear whether there will be more 2.7 full releases (and if so, when), and due to criticality of this fix it seemed better to release micro-patch at this point.

As to 2.8: set of fixes is rather short, still:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8.9

so I'll think of whether I should similarly release 2.8.8.1 as full release may take time (although there will certainly still be 2.8.9 as 2.9 is not yet released).

If anyone feels urgency wrt 2.8 please let me know.

[logan2013]

Everyone: Any impact on version 2.1.0?

thank you in advanced

[cowtowncoder]

@logan2013 Yes, if (and only if):

1. Object model is using either "default typing", or @JsonTypeInfo with nominal base type of java.lang.Object (or one of small number of tag-on "tag" types like java.io.Serializable and perhaps java.util.Comparable)
2. JSON content comes from untrusted source, that is, someone can craft specific JSON message.

If so, there is at least one reproduction of an issue.

Now: as to versions prior to 2.7: I have a plan to implement a new Jackson module which can be used with ALL 2.x versions, including 2.1.0. This may take bit more time, but would be more useful than handling within jackson-databind.

I hope this helps.

[alexchenfeiyu]

@cowtowncoder Hello, our product used 2.8.1, we need to solve the problem urgently.How can we do? We hope your help!
Thank you in advance

[ycrxun]

Everyone: Any impact on version 1.x?
thank you in advanced

[paulwong888]

@cowtowncoder any impact on jackson 2.7.5 + JDK 1.7 and above?

[cowtowncoder]

@alexchenfeiyu Do you know the vulnerability and that it affects you? I appreciate your general concern, but the vulnerability is quite specific and does not apply to majority of users.
Anyway: I will go ahead now and release 2.8.8.1: it will be available within couple of hours.

@ycrxun In theory yes, versions 1.5 and above.

@paulwong888 As per above, not very specific to Jackson version: but you may want to use jackson-databind 2.7.9.1 since it's the first one to have the fix.
However: it is possible JDK version matters; might not work on later JDK versions -- but I don't have specific knowledge that it would be prevent by particular version. Using latest JDK from given line could be safer (depends on embedded version of XSL engine JDK bundles).

As to vulnerability, this only applies to polymorphic type handling via default typing (or especially annotated @JsonTypeInfo on java.lang.Object type property) -- and obviously JSON crafted by untrusted third party.

[shellb0y]

@cowtowncoder I did not find the 2.8.8.1 url ，please provide this url, thank you!

[shellb0y]

I found it。
Because we do not know the way of repair, we need diff。

[hcc218]

Hello,everyone:Any impact on version 2.5.x and 2.9.0.prx?
thank you in advanced

[hcc218]

@shellb0y Have you found the 2..8.8.1 url ? Please provide this url , thank you very much!

[mrniko]

Is it possible to make fix for 2.6.x as well?

[cowtowncoder]

@mrniko Eventually yes, via separate module. 2.6 branch and older are closed for general releases however.

But if anyone wants to take time for PR (from 2.7 or whatever) I could merge too, push micro-patch 2.6.7.1.

[shellb0y]

@hcc218 https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.8.8.1

[shellb0y]

2.8.8.1 Plus the filter：
s = new HashSet<>()
String full = type.getRawClass().getName();
if (_cfgIllegalClassNames.contains(full)) {
}

[greuff]

How about we can configure a whitelist instead of a blacklist, i.e. a list of _accepted_ deserialization objects?

[cowtowncoder]

@greuff Perhaps white-listing would make sense for "security module" that I mentioned above.
I don't think it is good as a default, due to existing usage (and as it works fine for many users), but as an additional option I am sure it would be useful.

Further aspect to consider:

1. It may be that limitations for some namespaces (java.*, for example) should be stricter than others (so perhaps allow some level of configuration wrt Java packages under which rule is opt-in)
2. Since problem only (or mostly?) concerns POJO-serialization -- it comes from calling setters and/or directly setting fields -- , and not Collections or Maps, so most likely these types should not be checked (so that things like, say, Guava collections etc would not be blocked)
   
   
   
   • ... although since constructors are called, theoretically there is a possibility of some exploit(s)
   
   
3. Amount of configuration needed to white-list types grows by size of project, so this feature might have unfortunate property of becoming more PITA when project grows (low initial cost, high eventual)

[greuff]

I agree, whitelisting should be optional. If we could use wildcards we could whitelist com.myproject.model.* for example.

[mbechler]

Maybe I should also add a word of warning here. I've been doing quite a bit of research on the fundamental issue here (and also previously discussed some of it with @cowtowncoder ). Using that type of polymorphism on untrusted data is just unsafe in general (essentially because it allows an tremendous amount of code - that noone really knows what it is doing - to be triggered). If I haven't missed something the issue described here is only exploitable under quite specific circumstances. But stuff like that is way more common than one might imagine, an upcoming paper (hoping to finally publish it next weekend) of mine will detail a couple of others that can be exploited more readily and generally. The only way to make it reasonably safe is explicit whitelisting in some form.

Apart from the possible modularity problems with it (maybe this is something that could be improved), I would urge anyone to use registration/name based polymorphism instead if you are operating on possibly untrusted data.

I would also like to note that using any of the blacklists built for Java serialization won't help much, as the interactions are quite different, overlap between the exploitable instances should be rare (at least when using default visibility constraints).

[cowtowncoder]

@mbechler +1 to all of that. We need to figure out educational part of strong recommending avoiding class name based, unless source is fully trusted.
Looking forward to your paper, sounds really interesting (if there is a draft I would like to see that too, but if not published versions will do nicely).

Having said that I really hope to get jackson-module-security (or whetever better name there is) started. I think more configurable, modular, perhaps dynamic (allowing loading of external lists) approach makes sense. I am talking to a colleague who might be interested in ownership of this module; and I would be happy to get other experts involved as well. This is one area where keeping up with another domain (of sec vulns), timely updates, would be important; and it's quite distinct in many ways from maintaining core databinding which at this point is and needs to move bit slower.

[PianZi1110]

nice

[mbechler]

@cowtowncoder
Some more delays, but finally published: https://github.com/mbechler/marshalsec

[cowtowncoder]

Note: Jackson 2.8.9 patch version released, full set.

[zaodian17]

how to fix versions 1.5 and above？

[cowtowncoder]

@zaodian17 I assume the easiest route would be to register a Module that blocks attempts to create deserializers for suspicious types.

And actually I think this:

https://github.com/FasterXML/jackson-1/pull/5

adds such protection for 1.9. There'd need to be build 1.9.14.

[shorea]

But if anyone wants to take time for PR (from 2.7 or whatever) I could merge too, push micro-patch 2.6.7.1.

@cowtowncoder We (AWS SDK for Java) are interested in backporting this to the 2.6.x version of Jackson so our customers aren't forced to upgrade. Would you still be willing to accept a backport patch for this fix and release it to MavenCentral?

[cowtowncoder]

Fwtw, there is 2.6.7.1 release of jackson-databind now.

[cowtowncoder]

So: this is apparently this is reported as CVE-2017-7525 (https://bugzilla.redhat.com/show_bug.cgi?id=1462702).
And explained further in https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf

[ddillard]

Does anyone know when CVE-2017-7525 is going to be published in the NVD? I see that it was created at least as early as July 16, here it is November 2 and it's still not published.

[cowtowncoder]

For sake of completeness, list of fixed-in versions at this point is:

• 2.6.7.1
• 2.7.9.1
• 2.8.9
• 2.9.0

[lukaszlenart]

Do I get it right that the default typing isn't enabled by default?

[cowtowncoder]

@lukaszlenart Absolutely, it is not the default for Jackson. It is possible that some frameworks could enable it, but I really hope they do not -- I do not think it is a setting that makes sense as the baseline, both for security reasons and for basic ergonomics. To me at least it is quite specific setting that one might want to use when replacing JDK serialization, for internal storage, checkpointing or such usage.
But never for public (REST) endpoints.

[cowtowncoder]

Note: there will soon be 2.8.11 as well, to address further work at #1855.

[lukaszlenart]

@cowtowncoder thank you for the explanation, I was struggling with this question for some time and cannot find a clear answer :)

[lukaszlenart]

One more question because this isn't clear to me: using @JsonTypeInfo anywhere in an app enables default typing, is that true?

[cowtowncoder]

@lukaszlenart No. You can think of it as reverse: enabling default typing is about same as adding @JsonTypeInfo either on all classes, or on all properties.

So adding @JsonTypeInfo only enables polymorphic typing for either:

1. Properties of type X (when added to declaration of class X)
2. Specific property annotated.

and even then it will only allow subtypes of the property. So vulnerability would only apply property like:

@JsonTypeInfo(....)
public Object value;

where any type is accepted as a subtype. But would not apply, for example, for:

@JsonTypeInfo(....)
public MyBaseType value;

where only real subtypes are accepted, ever.

You can still override handling, too, to disable polymorphic handling for specific type (Class) or property, by using @JsonTypeInfo(include = As.NONE) (or something similar, I forget exact setting).

[lukaszlenart]

Nice, thank you :)

[fv3386]

I use jackson-databind 2.9.3 which depends on jackson-annotations 2.9.0, will this cause problems? Do I need to upgrade all jackson related jars to 2.9.3?

[cowtowncoder]

@fasterxml-travis No: jackson-annotations is quite special in that it only declares annotation types, and as a general rule there should be no differences at all between all 2.9.x versions (and same for all 2.x minor patches). In Jackson 3.x we will only have 3.0, 3.1 and so on, to remove this one source of confusion.

So: 2.9.0 is fine; 2.9.3 is also fine. They do not have code differences (*)

(*) For sake of completeness: there happens to be one actual packaging difference: 2.9.1 and above have Java 9 module declaration compiled in. Otherwise patches are identical.

[ksuresh8]

does this vulnerability affect jackson-databind v2.3.3?

[cowtowncoder]

@ksuresh8 yes. All 2.x versions not specifically included as having the fix will have it.

[swankjesse]

Have you considered disabling this feature when the target field’s type is java.lang.Object, Comparable, etc.? That would quickly cut down the attack surface.

[cowtowncoder]

@swankjesse Unfortunately ability to use that base type is a big use case (equivalent of JDK serialization, with all the warts), so those can not really be blocked without breaking some of existing usage. Especially since library can not really determine if content is trusted or might come from untrusted source.

But I think adding a MapperFeature that would add such limits is indeed something that might make sense -- and making that feature enabled by default for 3.0.

That is the loose plan anyway, so that although it will be possible to allow unsafe (potentially unsafe) usage it should require bit more work. As things are one has to enable default typing (or unsafe base type for @JsonTypeInfo), but it is not obvious that there are security considerations.

There is also some related discussion on #1866 as well as at:

https://github.com/FasterXML/jackson3-dev/issues/21

although I may not have added an issue for MapperFeature to perhaps add in 2.9 (which is against SemVer, but 2.9 is likely the last 2.x version so... may be lesser evil. Unless I'll change my mind and do 2.10 yet)

[cowtowncoder]

For further info: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062