On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> 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.
But is there a use case for partially hardened jars? Surely if there are additional vulnerabilities they need to be fixed as well? Using system properties simpifies things for Commons developers, however it makes it harder for consumers, as they have to ensure that the property is set. This may be hard to check if the jar is part of a large system. Though it would allow for certain vulnerabilities to be disabled by default (i.e.one has set a property to enable the risky code - [*]) and others only on demand. [*] This approach is already taken by the JDK with sun.net.http.allowRestrictedHeaders See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110 > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
