commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Date Sat, 07 Nov 2015 10:19:25 GMT
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.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message