On 11/08/2015 01:32 PM, Mark Thomas wrote: > On 08/11/2015 10:18, Thomas Neidhart wrote: >> On 11/07/2015 11:19 AM, Mark Thomas wrote: >>> 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. >> >> my idea was to have a binary compatible drop-in replacement that does >> not require any configuration, so that people that happen to have >> commons-collections 3.2.1 in their classpath can replace it with a >> hardened version. >> >> But I am open to other suggestions, in the end it is important to do >> what affected users would like to have to mitigate the problem. > > My main concern with a hardened JAR is that, while with just this > vulnerability, we end up with two JARs but how many JARs will we end up > with 3 or 4 vulnerabilities down the line. Particularly when fixing a > vulnerability means breaking functionality. I think system properties > scale better.
with the default being: do not de-serialize InvokerTransformer? Then I would be ok going that route. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
