commons-dev mailing list archives

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

Other ways to fix this issue seem to be quite complex, i.e. change the
way serialization is performed (use whitelisting, ...), and will most
likely not be executed in a timely manner. I wonder if some people
already ship a collections version with this class being
removed/manipulated, or use a runtime weaving technique to remove the
serialization support from it?

Setting up a reasonable security policy for this line of attack also
seems to be futile as it would have to be so restrictive that most
applications probably wont work anymore.

> So it seems to be a good idea to discuss some hardening. Unfortunatelly
> having a hardened distribution with only this one class removed might
> be a bit overkill. Are there other candidates to be left out in such a
> more specific distribution? Maybe everything proxy/reflection related?

I checked the codebase, and there are other Invoker* type classes but
they all use internally the InvokerTransformer.

> Both sample payloads have "gadget chains" which do start (readObject())
> in JCL classes and then use pretty generic interfaces like Annotations
> or Comparators, so there is really no link between the types and the
> specific weakness.

I did not see JCL (commons logging?) used in the gadget chains.

btw. the technique using the TransformerImpl from xalan (which is part
of the oracle/openjdk jre) is really scary as it allows an attacker to
inject arbitrary bytecode.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message