On 07/11/2015 10:13, Thomas Neidhart wrote: > On 11/07/2015 04:25 AM, Bernd Eckenfels wrote: >> 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. > > it is clear that the InvokerTransformer by itself does not have a bug, > but due to the way how java serialization is applied and considering the > fact that at least collections-3.2.1 is used *a lot* it would make sense > to provide a hardened version of collections to give people a chance to > easily avoid this line of attack in their application. > > Instead of removing the class we could prevent de-serialization of it in > the hardened jar. This would not break b/c and it is very unlikely that > the InvokerTransformer is serialized in legit ways.
Rather than having hardened vs unhardened JARs, it would probably be better to use a system property to enable/disable the behaviour. I don't know the code or the vulnerability well enough to know exactly where to put this switch so it prevents the attack but has minimal impact on other uses. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
