Difference between revisions of "Deserialization of untrusted data"

Revision as of 20:09, 16 November 2015

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

Last revision (mm/dd/yy): 11/16/2015

Vulnerabilities Table of Contents

Description

Data which is untrusted cannot be trusted to be well formed. Malformed data could be used to abuse application logic, deny service, or execute arbitrary code.

Consequences

• Availability: The logic of deserialization could be abused to create recursive object graphs or never provide data expected to terminate reading.
• Authorization: Potentially code could make assumptions that information in the deserialized object about the data is valid. Functions which make this dangerous assumption could be exploited.
• Access control (instruction processing): malicious objects can abuse the logic of custom deserializers in order to affect code execution.

Exposure period

• Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
• Implementation: Not using the safe deserialization/serializing data features of a language can create data integrity problems.
• Implementation: Not using the protection accessor functions of an object can cause data integrity problems
• Implementation: Not protecting your objects from default overloaded functions - which may provide for raw output streams of objects - may cause data confidentiality problems.
• Implementation: Not making fields transient can often may cause data confidentiality problems.

Platform

• Languages: C, C++, Java, Python, Ruby
• Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

Medium

It is often convenient to serialize objects for convenient communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security - which is of course a dangerous security assumption.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the non-transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

Risk Factors

• Does the deserialization take place before authentication?
• Does the deserialization limit which types can be deserialized?
• Does the deserialization host have types available which can be repurposed towards malicious ends? Sometimes, these types are called "gadgets", considering their similarity to abusable bits of code that already exist in machine code in [[1]] attacks.

Examples

The following is an example from Adobe's BlazeDS AMF deserialization vulnerability. You can specify arbitrary classes and properties for a BlazeDS application to deserialize. This particular payload creates an instance of a JFrame on the target server. The created JFrame will have a "defaultCloseOperation" of value 3 -- which indicates that the JVM should exit when this JFrame window is closed.

[RemoteClass(alias="javax.swing.JFrame")]
public class JFrame {
   public var title:String = "Gotcha!";
   public var defaultCloseOperation:int = 3;
   public var visible:Boolean = true;
}

The next example is one that is much more likely to be seen in custom code. This code reads an object from an untrusted source, and then casts it to an AcmeObject:

InputStream is = request.getInputStream();
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();

Unfortunately, the casting operation to AcmeObject occurs after the deserialization process ends. Therefore, it's not useful in preventing any attacks that happen during deserialization from occurring. It's possible that behavior in custom deserialization protocols (for instance, by overriding Serializable#readObject() in Java) can be re-purposed towards malicious ends.

Related Controls

• Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
• Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
• Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
• Implementation: Explicitly define final readObject() to prevent deserialization.

An example of this is:

private final void readObject(ObjectInputStream in)
throws java.io.IOException {
     throw new java.io.IOException("Cannot be deserialized");
}

• Implementation: Make fields transient to protect them from deserialization.
• Implementation: Override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized.

References

• FoxGlove vulnerability announcement
• JFrame DoS example by Wouter Coekaerts