Apache Commons Collections Security Vulnerabilities (commons-collections-3.2.1.jar)

[Rchu]

Hi,

Our security team report the security vulnerabilities caused by Apache Commons Collections (commons-collections-3.2.1), which is packed in the SmartClient package and is used in our product.

From Apache, the issue is described as the following:

"High: Remote Code Execution during object de-serialization

The Apache Commons Collections library contains various classes in the "functor" package which are serializable and use reflection. This can be exploited for remote code execution attacks by injecting specially crafted objects to applications that de-serialize java objects from untrusted sources and have the Apache Commons Collections library in their classpath and do not perform any kind of input validation."

For the defect detail, please check https://commons.apache.org/proper/co...y-reports.html.

The issue is fixed in commons-collections4-4.1 and we are trying to upgrade the lib to commons-collections4-4.1. However, there are lots of dependencies in SmartClient code to use the old library and we are not able to make it.

We are currently using SmartClient v9.1p_2015-02-17 Power Edition. We checked the latest SmartClient_v91p_2017-03-22_PowerEdition and SmartClient_v110p_2017-03-29_Evaluation, commons-collections-3.2.1 is still used.

Could you please advice how could we upgrade the commons-collection to the latest commons-collections4-4.1?

Thanks,
Robin

[Isomorphic]

SmartClient is not affected by this vulnerability since we don't use Java serialization.

However if you need to fulfill some sort of corporate checklist anyway, you should be able to bump a minor version (to 3.2.2) as that also had the fix.

[Crack]

SmartClient itself may be unaffected, but the vulnerability manifests when bad version of commons is present in classpath and application uses Java deserialization. So, if an application uses deserialization and depends on SmartClient with all of its dependencies in recommended versions then it becomes potentially vulnerable.

[Isomorphic]

Yes, and if your application makes itself vulnerable by using Java serialization with untrusted data, you can solve this by bumping from 3.2.1 to 3.2.2 without worries of backward compatibility.

[Rchu]

Thanks for the information and upgrading to 3.2.2 seems solve the serialization security issue.

However, there is another security vulnerability on Apache POI, which need to upgrade to commons-collections4 library.

According to https://poi.apache.org/ , poi-3.15 fixed a security vulnerability related to XEE attack.

"Apache POI in versions prior to release 3.15 allows remote attackers to cause a denial of service (CPU consumption) via a specially crafted OOXML file, aka an XML Entity Expansion (XEE) attack. Users with applications which accept content from external or untrusted sources are advised to upgrade to Apache POI 3.15 or newer."

SmartClient is using POI-3.14. We are trying to upgrade the POI to 3.15 but it adds dependency on commons-collections4 lib. Therefore, without upgrading to commons-collections4, we are not able to make it.

For POI-3.15 release note, please check https://poi.apache.org/changes.html#3.15. It has the following statement:
"Version 3.15 (2016-09-19)# : Add Apache commons-collections4 dependency (breaks backwards compatibility)"

Thanks,
Robin

[Isomorphic]

Commons 3 and 4 can both be on the class path as they were placed into different namespaces.

[Isomorphic]

Quick FYI: We've now bumped the distributed version of commons-collections from 3.2.1 to 3.2.2 across all supported builds.

[Blama]

Hi Rchu,

According to https://poi.apache.org/ , poi-3.15 fixed a security vulnerability related to XEE attack.

"Apache POI in versions prior to release 3.15 allows remote attackers to cause a denial of service (CPU consumption) via a specially crafted OOXML file, aka an XML Entity Expansion (XEE) attack. Users with applications which accept content from external or untrusted sources are advised to upgrade to Apache POI 3.15 or newer."

From my understanding the framework only exports files. If POI is also able to import files it seems to me that these functionality is not used.

Best regards
Blama

[Rchu]

Putting both commons 3 and 4 on the class path works for us.

Thanks,
Robin