Software Engineering Institute

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.

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.

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.