commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Wiedmann <jochen.wiedm...@gmail.com>
Subject Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Date Sun, 08 Nov 2015 14:49:48 GMT
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
View raw message