Hello Gary, if we can release a fixed version quickly I would agree, but it is not really needed for a reply to the ongoing FUD.
A statement would be "the dicovered vulnerability is in applications using JavaObject serialisation from untrusted sources and not implementing additional precaution like whitelists or restricted classloaders, it is not in one of the many example classes used by the POC exploits. Neighter Spring, Groovy or Apache Commons are responsible for the security bug. Even tough, Apache Commons plans to add some infrastructure for restricting the currently most often used class for "gadget chains" to not suport de-serialisationby default. This will be provided for 3.2 and 4.0 branches (with an programmatic and system property option to turn the old behavior back on)" I havent blogged on the ASF blogs yet, but I would be willing to write on a text like that. Gruss Bernd Am Sun, 8 Nov 2015 10:22:12 -0800 schrieb Gary Gregory <garydgreg...@gmail.com>: > Hi All: > > What about agreeing on a plan before we post anything? My proposal > would be to follow up on an idea posted on the dev ML: Use a system > property to enable the risky feature. This would change the default > behavior to disallow the feature. And possibly add a new config > option on the problematic class to control the behavior > programatically. If the prog config would override the sys prop. We > can release a 3.x and 4.x version once we agree on a plan and then > blog about it again. > > Thoughts? > > Gary > > On Sun, Nov 8, 2015 at 10:10 AM, Gabriel Lawrence < > gabriel.lawre...@gmail.com> wrote: > > > If you guys want to put together a blog post about this, Chris and > > I would be happy to help. We've tried to be pretty clear to people > > that this isnt a problem with the libraries, but something that > > should be addressed by the deserializer either by not deserializing > > from a trusted source or by hacking in their own way to whitelist > > types allowed to be deserialized. > > > > I think the core message is that object instantiation is code > > execution, don't give untrusted folks the ability to instantiate > > arbitrary objects or you are going to have a bad day. Pulling > > together gadgets is a painful search, but the idea that you can > > find them all and eliminate them seems flawed. There are likely > > going to be things in your classpath that do stuff similar to the > > set of gadgets Chris found that rely on the apache library in tuns > > of other class libraries as well. > > > > Let us know. Since this broke out on twitter we've both been trying > > hard to get the description of the root of the problem to be > > changed. But, it seems to have stuck for some reason... maybe > > because having it be a simple fix is just more desirable to > > people :-) Even when it isn't. > > > > gabe > > > > On Sun, Nov 8, 2015 at 1:41 AM, Benedikt Ritter <brit...@apache.org> > > wrote: > > > > > Hi, > > > > > > there is a lot of bad talk going on at twitter [1,2,3] and I'm > > > wondering whether we should respond to this via the Apache blog. > > > > > > Thoughts? > > > Benedikt > > > > > > [1] https://twitter.com/JustineTunney/status/662937508980723712 > > > [2] https://twitter.com/kennwhite/status/662709833464872960 > > > [3] https://twitter.com/jodastephen/status/663253106751180800 > > > > > > > > > -- > > > http://people.apache.org/~britter/ > > > http://www.systemoutprintln.de/ > > > http://twitter.com/BenediktRitter > > > http://github.com/britter > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
