Does SpringFramework use InvokerTransformer from commons.collections?

De-serialization Vulnerability (CVE-2015-4852) announced yesterday:

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

SpringFramework uses commons.collections.

If SpringFramework uses the InvokerTransformer, it may be vulnerable to the de-serialization vulnerability (CVE-2015-4852).

Question: Does SpringFramework use InvokerTransformer from commons.collections?

+5
source share
2 answers

3. Update . This is Jรผrgen Hรถller's answer to my Jira Questions :

The Spring Framework does not use Commons Collections in any way. if you have it on the way to the class, it may just be for another dependency that you have chosen, for example OpenJPA.

However, we have a related issue in SPR-13656, where we were fixing our class to prevent abuse in such scenarios. Note that this only matters if you serialize endpoints to untrusted clients. Spring is not exposed by default; rather, your application is clearly choosing to use HTTP Invoker or RMI Invoker.

Jurgen


2. Update : Spring Framework versions 4.2.3 and 4.1.9 are not vulnerable to a related issue.


I was looking for a spring-framework project and still have not found the use of org.apache.commons.collections.(Transformer|InvokerTransformer|MapTransformer) . This does not mean that some Spring subprojects use InvokerTransformer .

A quick search on jira.spring.io did not reveal any problems 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

Perhaps the spokesperson may clarify this.

Update . I filed Problems with Jira .

+4
source

I believe this question is incorrect.

Good question for this CVE: is a collection of apache collections in the classpath? (more specifically InvokerTransformer)

If so, the application is permanently vulnerable if it immediately deserializes objects from any unsafe sources.

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

The problem is mainly related to the possibilities of serialization and deserialization ... Thus, InvokerTransformer is only the visible part of the iceberg of dangerous methods. Although, this is one big and simple hit.

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

+1
source

Source: https://habr.com/ru/post/1235758/


All Articles