Hello, I tried to raise that concern in the message already, but it is probably worth repeating it explicitly: this is not a real bug in the Commons-Collection class, and it might not be worse fixing it, as there are possibly tons of other vectors. This was also addressed by the original authors in the talk and even here on Twitter:
https://twitter.com/gebl/status/662754611304996866 however, as the "foxglove" article shows, people still point at the apache project, and after all it is good pratice to reduce footprints and attack surfaces. So it seems to be a good idea to discuss some hardening. Unfortunatelly having a hardened distribution with only this one class removed might be a bit overkill. Are there other candidates to be left out in such a more specific distribution? Maybe everything proxy/reflection related? Both sample payloads have "gadget chains" which do start (readObject()) in JCL classes and then use pretty generic interfaces like Annotations or Comparators, so there is really no link between the types and the specific weakness. Greetings Bernd Am Sat, 7 Nov 2015 00:56:00 +0100 schrieb Thomas Neidhart <thomas.neidh...@gmail.com>: > On 11/06/2015 10:25 PM, Bernd Eckenfels wrote: > > ello, > > > > I came across this article: > > > > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ > > > > It describes attacks against common Java applications with > > pre-authentication requests using malicious Java Object > > serialisation. It builds upon the work of Gabriel Lawrence (@gebl) > > and Chris Frohoff (@frohoff) (presented on January 28th, 2015, > > “Marshalling Pickles” given at AppSecCali) > > > > http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles > > > > The ysoserial tool has some sample payloads, two use > > commons-collection oac.collections.functors.InvokerTransformer. * > > > > https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads > > > > The class itself is rather handy to break out of the readObject() > > chains to execute arbitrary methods. > > > > I do'nt recall any discussion here about this > > class. Is this currently handled/reported? Of course the more > > general problem is using serialisation with untusted peers, and if > > commons-collection fixes this, there might still be other vectors, > > but still I think it would be good to do something against that > > "bad press"? > > I was not aware of this yet, thanks for the pointers. > > If we would remove the problematic classes and release a new > collections version (for the 3.x or 4.x branch) we would break source > and binary compatibility. > > It might be acceptable/doable to release a collections version with an > additional maven classifier (e.g. -hardened) that removes the relevant > classes and explain the compatibility issues in detail in the release > notes. What do others think about something like that? ... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
