commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Date Sun, 08 Nov 2015 18:44:38 GMT
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 <gudnabrsam@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.wiedmann@gmail.com>
> wrote:
>
> > Makes sense.
> >
> >
> > On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <garydgregory@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.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
> > >>
> > >>
> >
> >
> >
> > --
> > 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