Makes sense.
On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > I like the property option as a stopgap. > > Should we add a programatic option so that programmers can also control > this on a per invoker basis? > > Gary > On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <jochen.wiedm...@gmail.com> wrote: > >> I like the property based approach. In particular, because we can >> evaltuate that property within >> >> private void readObject >> >> Or, in other words: We can ship a jar that has the vulnerability >> disabled by default (property isn't set). However, if the user >> attempts to deserialize an InvokerTransformer, he or she gets a clear >> and loud exception, that advices what to do (set the property). Should >> be a solution that makes everyone happy in the medium term. >> >> Jochen >> >> >> On Sun, Nov 8, 2015 at 3:30 PM, sebb <seb...@gmail.com> wrote: >> > 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 >> > >> >> >> >> -- >> The next time you hear: "Don't reinvent the wheel!" >> >> >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
