CERT Coordination Center

Apache Commons Collections Java library insecurely deserializes data

Vulnerability Note VU#576313

Original Release Date: 2015-11-13 | Last Revised: 2018-08-27

Overview

The Apache Commons Collections (ACC) library is vulnerable to insecure deserialization of data, which may result in arbitrary code execution. Java applications that either directly use ACC, or contain ACC in their classpath, may be vulnerable to arbitrary code execution.

Description

In January 2015, at AppSec California 2015, researchers Gabriel Lawrence and Chris Frohoff described how many Java applications and libraries using Java Object Serialization may be vulnerable to insecure deserialization of data, which may result in arbitrary code execution. Any Java library or application that utilizes this functionality incorrectly may be impacted by this vulnerability.

In November 2015, Stephen Breen of Foxglove Security identified the Apache Commons Collections (ACC) Java library as being vulnerable to insecure deserialization of data; specifically, the ACC InvokerTransformer class may allow arbitrary code execution when used to deserialize data from untrusted sources. According to the researcher, this issue affects several large projects that utilize ACC including WebSphere, JBoss, Jenkins, WebLogic, and OpenNMS. Unify also reports that OpenScape software is affected. In addition, Cisco has released an advisory for their products.

Both versions 3.2.1 and 4.0 of the Apache Commons Collections library have been identified as being vulnerable to this deserialization issue.

The Apache Software Foundation has released a statement regarding this issue, which contains advice for mitigating the issue, as well as further references and links. A bug tracker entry has been filed to track progress toward a full solution.

Other libraries, such as Groovy and Spring, are currently being investigated for similar flaws. Lawrence and Frohoff's presentation describes how applications and libraries written in other languages, such as Python and Ruby, may also be vulnerable to the same type of issue. It is generally up to software designers to follow best practices for security when handling serialized data, no matter the programming language or library used.

Impact

A Java application or library with the Apache Commons Collections library in its classpath may be coerced into executing arbitrary Java functions or bytecode.

While many applications do not actively use serialization or deserailization, they often rely on libraries that do. If a class uses deserialization on some input stream (either a file or socket), and an attacker can send malicious data down that stream, the attacker can cause the program to construct objects of any class on its classpath (whether it uses those classes or not). And some classes, such as those in the ACC automatically execute code based on attacker-supplied deserialization input.

An application that neither uses deserialization, nor employs any libraries that use deserialization, would not be vulnerable to this problem. Such an application should also lack a plugin architecture, or any mechanism for loading code that might use deserialization.

Solution

The CERT/CC is currently unaware of a full solution to this problem, but you may consider the following:

Apply an update

Apache Commons Collections version 3.2.2 and version 4.1 has been released. These new releases mitigate the vulnerability by disabling the insecure functionality.

Developers need to re-architect their applications, and should be suspicious of deserialized data from untrusted sources

Developers will need to make further architectural changes to secure their applications before they can re-enable functionality in ACC version 3.2.2 and later. From Apache's statement:

However, to be clear: this is not the only known and especially not unknown useable gadget. So replacing your installations with a hardened version of Apache Commons Collections will not make your application resist this vulnerability.

System administrators may be able to mitigate this issue for some applications by restricting access to the network and/or filesystem. If an affected application, such as Jenkins, utilizes an open port accepting serialized objects, restricting access to the application may help mitigate the issue.

Vendor References

Addendum

As of 2017-07-18, CERT/CC is aware of a report that Cisco Unity Express (CUE) 8.6.1 is still vulnerable to this issue and is incorrectly identified as "not vulnerable" in the above Cisco advisory. We have reached out to Cisco for clarification.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

IBM Corporation

Updated: November 30, 2015

Status

Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

IBM has released a security advisory for WebSphere at the following URL:

Addendum

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Unify Inc

Updated: November 30, 2015

Statement Date: November 24, 2015

Status

Affected

Vendor Statement

"Unify is affected in two product lines as listed below. For details refer to the information given in the Security Advisory OBSO-1511-01.

We recommend all customers to apply the mitigations described in the advisory and install the corresponding product fix releases as soon as available.To get notified about Advisory updates, subscribe as listed in https://www.unify.com/security/advisories."