The problem is that we provide them a means to invoke a method on an object. On Sun, Nov 8, 2015 at 1:43 PM Matt Benson <gudnabr...@gmail.com> wrote:
> I'm only tangentially following this, but if the problem is that an > attacker can supply malicious bytecode, then wouldn't a programmatic e.g. > property be just as easy [for an attacker] to pass in? This would need to > be a transient property, if included, right? > > Matt > On Nov 8, 2015 8:50 AM, "Jochen Wiedmann" <jochen.wiedm...@gmail.com> > wrote: > > > 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 > > > > >
