Insecure Deserialization Explained

Why developers serialize and how it can go wrong.

To understand insecure deserialization vulnerabilities, it's helpful to first understand normal uses of object serialization and deserialization. Object serialization and deserialization can be performed in many coding languages, e.g. PHP, Python, Java, and .Net. Serializing an object converts a coding object into a stream of bytes. Deserialization converts a stream of bytes back into the original object. By serializing an object, a developer can store or transmit values, state, and structure information specific to the coding language without the storage or transmission process needing to be aware of particulars of the language in which the object was created. For instance, a developer may need to pass a Linked-List object with multiple values and complex structure from one server to another. By using object serialization and deserialization, any transfer method can be used since the transfer process only needs to transmit a stream of bytes. The receiving server can then pass the stream of bytes to the coding language that knows how to reassemble (deserialize) the bytes into the original object.

To summarize: serialization turns an object into bytes; deserialization turns bytes into an object.

Vulnerabilities often arise in two common scenarios:

  1. An application performs tasks based on the values contained within an object, e.g. a developer codes logic that instructs an application to execute the commands contained within an object.

  2. The coding language automatically executes actions by attempting to deserialize the object, i.e. a vulnerability exists within the coding language libraries that causes execution when the application attempts to reassemble (deserialize) the bytes into the original object.

The vulnerability identified in Adobe LiveCycle ES4v11.0 is the second scenario. When the application attempts to deserialize the object, Java invokes and instantiates classes that result in commands being passed to the underlying OS. We achieved the correct instantiation chain by using a version of an opensource tool called ysoserial: a Java-specific tool for exploiting unsafe deserialization.

These vulnerabilities are referred to as insecure deserialization vulnerabilities because developers can mitigate these vulnerabilities through the following secure coding practices:

  1. Do not accept serialized objects from an untrusted source.

  2. Employ safe deserialization methods for the specified language. When creating an application, developers should investigate which deserialization methods are considered safe for the language in which they are coding.

References:

Last updated