Does SpringFramework use InvokerTransformer from commons.collections?

Question

Yesterday announced about de-serialisation vulnerability (CVE-2015-4852):

https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

SpringFramework uses commons.collections.

If SpringFramework use InvokerTransformer it can be vulnerable for the de-serialisation vulnerability (CVE-2015-4852).

The question does SpringFramework use InvokerTransformer from commons.collections?

Answer 1

3. Update: That is Jürgen Höller's answer to my Jira issues:

Spring Framework does not use Commons Collections in any way. If you have it on your classpath, it might just be behind another dependency that you chose, such as OpenJPA.

That said, we do have a related issue in SPR-13656 where we've been fixing a class of ours in order to prevent misuse in such scenarios. Note that this only matters if you are exposing serialization-based endpoints to untrusted clients. Spring does not do any such exposure by default; it's rather something that your application is explicitly opting into through the use of HTTP Invoker or RMI Invoker.

Juergen

---

2. Update: Spring Framework Version 4.2.3 and 4.1.9 aren't vulnerable to a related issue.

---

I searched the spring-framework project and didn't find any use of org.apache.commons.collections.(Transformer|InvokerTransformer|MapTransformer) so far. This doesn't mean that some Spring subprojects make use of InvokerTransformer.

A quick search on jira.spring.io doesn't revealed any issues right now:

https://jira.spring.io/issues/?jql=text%20~%20%22invoketransformer%22

https://jira.spring.io/issues/?jql=text%20~%20%22CVE-2015-4852%22

Maybe a Pivotal official can clarify this.

Update: I filed a Jira issues.

Answer 2

I believe the question is not the right one.

The good questionfor this CVE is: is apache commons collections in the classpath ? (more specifically InvokerTransformer)

If the answer is yes, application is definitively vulnerable if as soon as it's deserializing objects from any kind of unsafe sources.

If the answer is no, application is not vulnerable to Invokertransformer CVE, but is still potentially vulnerable to other kind of hacks if it's still deserializing objects from untrusted sources without proper checks.

The problem mostly comes from the capabilities of serialization and deserialization... So InvokerTransformer only is the visible part of the iceberg of unsafe practices. Though, that one's a big and simple hit.

Deserializing objects when serialized version is not under control means unpacking magic boxes.