commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Date Sun, 08 Nov 2015 14:47:19 GMT
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.wiedmann@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 <sebbaz@gmail.com> wrote:
> > On 8 November 2015 at 12:32, Mark Thomas <markt@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message