Security Advisory CVE-2015-4852 (Java Object Deserialization Vulnerability)

Information supplied by Robin Percy, and Robert Hawk and the xMatters Security Office.

On Tuesday, November 10, 2015, the National Vulnerability Database (NVD) announced the identification of the Java Object Deserialization Vulnerability. This vulnerability was assigned the identifier CVE-2015-4852 by the NVD at the National Institute of Standards and Technology.

The xMatters cloud-based service is not negatively affected by the CVE-2015-4852 vulnerability.

The xMatters Operations team analyzed exposure to CVE-2015-4852 and determined that while the xMatters cloud-based software-as-a-service application uses the affected code, it does not use the code for primary service delivery. The affected code is used only for carrying out specific operations within the protected sub-networks of the cloud environment, and presents no exposure to the public networks with which the xMatters cloud interfaces, such as the Internet and telecommunications providers.

Technical Analysis

When serializing a Java object (for example, when caching the object in a session), the java.lang.Serializable interface must be implemented by initializing an ObjectOutputStream and writing the object to that stream using oos.writeObject(myObject). When an object is deserialized, the serialized representation is loaded into an ObjectInputStream and (MyClass) ois.readObject() is called. This operation is standard, and not considered particularly unsafe.

The risk in the procedure is that Java allows custom behavior to be defined during serialization and deserialization. If a class overrides the readObject() and writeObject() methods, they will be invoked by the corresponding object stream methods. There is no indication to the ObjectInputStream what type of class to deserialize; it invokes the readObject() method on whichever class it determines the stream contains. This means that a vulnerable class just has to be on the class path (and therefore discoverable by ObjectInputStream) for its readObject() method to be invoked.

Fortunately, the object streams only work with a specific binary representation for objects. This exposure exists in places where an application (or an underlying library) tries to decode that format.

Simplified vulnerability and exposure

The vulnerability with Apache Commons Collections is due to a class' readObject() method expecting some serialized values to be method invocations (for developers, it may help to think of GoF Command Pattern). When handling these values, it resolves three values: class name, method name, and args. It then uses reflection to look up the class and invoke the method with the given args.

On its own, this does not allow arbitrary code execution, merely the execution of any method accessible on the class path. Some libraries, however, such as Groovy Runtime and some Sprint components, may have risky methods available, such as eval(). It is for this reason that security alerts make a point of calling out the added danger of some library combinations.

Summary of analysis

The first step in analyzing the vulnerability of the xMatters cloud-based platform to this type of exploit was determining which ports were exposed to the public network (i.e., the Internet). Unsurprisingly, the only exposed port is port 8888, required for HTTP/S traffic.

The next task was to determine if and where readObject() is called on serialized representations. A grep of the On-Demand and Integration Agent codebases returned only one call to readObject(), located within the CompressionUtility class. Further investigation revealed that this class is used only on internally-generated values for optimizing transit of messages, and is not called on raw user input.

Finally, third-party libraries were examined to identify any that might be using readObject() for deserialization of user data. While this seemed unlikely, the following areas of the application were marked as higher risks than others:

  • SOAP API: As SOAP deals with unmarshalling XML input, it was necessary to ensure that embedded binary objects are disallowed in requests. For example, IBM's WebSphere product allows JMX objects to be embedded in its SOAP requests. Given that the xMatters API is defined by and validated against a WSDL, the investigation focused on the object types and formats allowed by the WSDL. The Operations team extracted all parameter type names into one list, and all complex type definitions into another. By comparing these lists, it was confirmed that all of the internally-defined complex types are composed of primitive types (strings, inits, etc.) and no types are defined by third parties. There is therefore no apparent way that xMatters would accept binary data in the SOAP API.
  • REST API: The same concerns existed for the REST API as for SOAP, with the added concern that the REST API does not have a WSDL. The REST API is small enough, however, that it was possible to manually inspect and confirm that it does not accept binary content.
  • GWT: Some concern existed over the fact that GWT defines its own protocol, and it was unknown whether it used Java serialization to pass data between the client and server. Other investigations have reverse-engineered the protocol and confirmed that it uses a custom serialization format. The Operations team used the Burp Suite proxy/sniffer to inspect client-server communication while navigating and submitting GWT pages to verify consistency with the spec. For more information, see https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit
  • Cocoon: While Cocoon did not seem to be at risk, the Operations team decided, given its complex implementation, to capture a sample request and verify that all arguments were regular HTTP form data.
  • Ping.jsp: This page was raised as a concern prior to a full understanding of the nature and mechanics of this vulnerability. Although the page responds to anonymous requests, it does not perform custom serialization of user input, meaning there is no apparent vector of attack.

Conclusions

The risk of vulnerability to CVE-2015-4852 is likely very low for xMatters. Despite this assessment, it is recommended that the Operations team and xMatters as a whole remain cognizant and alert to any further developments related to the vulnerability, and re-evaulate should any further information, patches, and tools become available.

 

Resources

 

 

The information in this article is proprietary and confidential to xMatters and xMatters customers. Do not distribute or print.

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk