search menu icon-carat-right cmu-wordmark

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

CWE-502: Deserialization of Untrusted Data - CVE-2015-6420

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.

Developers should in general be very suspicious of deserialized data from an untrusted source. For best practices, see the CERT Oracle Coding Standard for Java guidelines for Serialization, especially rules SER12-J and SER13-J.

Use firewall rules or filesystem restrictions

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 Information

576313
 

Apache Software Foundation Affected

Updated:  November 10, 2015

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Cisco Affected

Updated:  July 18, 2017

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

Cisco has released a security advisory and list of affected products at the URL below. Cisco has assigned CVE-2015-6420 to this 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 Affected

Updated:  November 30, 2015

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

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

Vendor References

Jenkins Affected

Updated:  November 30, 2015

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

Jenkins has released a security advisory at the URL below. CVE-2015-8103 was assigned this issue in Jenkins.

Vendor References

Oracle Corporation Affected

Updated:  November 30, 2015

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

Oracle has released a security advisory at the URL below:

Vendor References

Unify Inc Affected

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."

Vendor Information

Unify has issued Security Advisory OBSO-1511-01 at the URL listed below.

Mitre had assigned two CVE IDs for Unify products impacted by VU#576313:

CVE-2015-8237, affected products:
Unify OpenScape Fault Management V7 ("cpe:/a:unify:openscape_fault_management:7.%02")
Unify OpenScape Fault Management V8 ("cpe:/a:unify:openscape_fault_management:8.%02")

CVE-2015-8238, affected products:
Unify OpenScape UC Application V7 ("cpe:/a:unify:openscape_uc_application:7.%02")
Unify OpenScape Common Management Platform V7 ("cpe:/a:unify:openscape_common_management_platform:7.%02")

Vendor References

Red Hat, Inc. Unknown

Updated:  November 30, 2015

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

JBOSS has been reported as being affected.


CVSS Metrics

Group Score Vector
Base 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P
Temporal 6.4 E:POC/RL:W/RC:C
Environmental 6.4 CDP:ND/TD:H/CR:ND/IR:ND/AR:ND

References

Acknowledgements

This type of vulnerability was reported publicly by Gabriel Lawrence and Chris Frohoff, and later investigated by Stephen Breen.

This document was written by Garret Wassermann with assistance from David Svoboda and the CERT Secure Coding team.

Other Information

CVE IDs: CVE-2015-6420
Date Public: 2015-01-28
Date First Published: 2015-11-13
Date Last Updated: 2018-08-27 17:57 UTC
Document Revision: 89

Sponsored by CISA.