Java deserialization flaws: Part 2, XML deserialization

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

All classes which implement the java.io.Serializable interface can be serialized and deserialized, with Java handling the plumbing automatically. In the first part of this two-part series, we looked at some of the unexpected security consequences which can arise from usage of binary deserialization in Java applications. This second part of the series will focus on security issues related to XML deserialization.

XML Deserialization

An alternative approach to Java's native binary serialization is XML serialization, where the state of in-memory objects is represented as an XML document. XML serialization capabilities are provided by a number of commonly-used libraries. The Java Architecture for XML Binding (JAXB) is the standard implementation, which is available as part of the Java runtime environment, and as a standard API in J2EE environments. Several other XML serialization libraries exist - this article will focus on just two: XMLDecoder and XStream, both of which have exposed serious security issues in recent releases.

XMLDecoder

XMLEncoder/XMLDecoder are components in the Java Development Kit (JDK) that provide long term persistence for Java beans, using an XML serialization format to achieve this. This functionality is very powerful, as the XML format can represent a series of methods that will be called to reconstruct an instance of the object. If an application uses XMLDecoder to deserialize content provided by a user, then the user could inject arbitrary code into the specification of methods to call when reconstructing the object. In other words, any application that allows a user to pass content that will be deserialized by XMLDecoder is exposing a remote code execution flaw.

Dinis Cruz et. al. reported that the Restlet REST framework did just this, using XMLDecoder to deserialize the content of XML REST API requests. This flaw was assigned CVE-2013-4221, and was patched by disabling the vulnerable functionality. While researching this issue, it was also found that Restlet provided similar functionality using binary serialization. This would not expose remote code execution by default, but could expose various security issues, as described in the first article of this series. The binary deserialization flaw in Restlet was assigned CVE-2013-4721, and was also patched by disabling the vulnerable functionality.

XStream

XStream is an open source library, external to the JDK, which aims to simplify XML serialization and deserialization. It is popular due to its ease of use. XStream does not allow the specification of deserialization logic as XMLDecoder does. However, Dinis Cruz et. al. also reported that XStream's reflection-based approach to deserialization can be used to achieve arbitrary code execution when deserializing user-supplied XML. XStream will deserialize classes of any type. It has a special handler for dynamic proxy instances, which will resolve the implemented interfaces and handler. This allows an attacker to provide XML representing a dynamic proxy class, which implements the interface of a class the application might expect, then also implements a handler that calls arbitrary code when any of the members of the deserialized class are called.

There has been debate within the community as to how this should be resolved. Any application that is deserializing arbitrary user-supplied input is potentially vulnerable to a variety of security issues, as discussed in this series of articles. Should it then be considered a concern for applications using XStream to resolve? Some applications have already done so.

It was found that Spring OXM provided an XStreamMarshaller class, which would by default expose the remote code execution issue. Spring addressed this in documentation, warning users to apply a class type whitelist using a configuration property. It was also found that Sonatype Nexus was using XStream in a fashion that exposed an unauthenticated remote code execution flaw. This was addressed by forking the XStream library, and adding a patch that introduces support for class type whitelisting. Concurrently, the XStream project itself is now working on a patch that introduces support for class type whitelisting. The whitelisting will be disabled by default in the next minor release to maintain backwards compatibility, but will be enabled by default in the next major release. The flaw as it pertains to XStream itself has been assigned CVE-2013-7285.

Conclusion

XML serialization is potentially very dangerous when used to transport untrusted, user-supplied data. In addition to the problem of vulnerable serializable classes that is exposed by binary serialization, XML serialization also introduces several other possibilities for exposing remote code execution flaws. As an application developer, the take-home message is simple: never deserialize untrusted content using any Java serialization format. Content should always be checked to ensure that it is of an acceptable type prior to deserialization.