A Deep Dive into Java Deserialization Vulnerabilities shows Libraries are Loopholes

The Java Programming Language is a general-purpose, concurrent, strongly typed, class-based object-oriented language. It is normally compiled to the bytecode instruction set and binary format defined in the Java Virtual Machine Specification. In a best-case scenario, deserialization vulnerabilities may simply cause data corruption or application crashes, leading to a denial of service (DoS) condition. Many times, the same bugs can be triggered by remote attackers to achieve arbitrary code execution capability on the vulnerable system. Insecure deserialization vulnerabilities involve the use of unknown or untrusted data and can result in attacks such as denial of service (DoS), malicious code execution, bypassing authentication measures or other abuses of application logic.

What is serialization in Java?

We use Java to create objects. These objects are stored in memory and removed by the garbage collector once they're no longer being used. Serialization in Java is a mechanism of writing the state of an object into a byte-stream. It is mainly used in Hibernate, RMI, JPA, EJB and JMS technologies. If we want to transfer an object and, for instance, store it on a disk or send it over a network, we need to transform it into a byte stream. To do this, the class of that object needs to implement the Serializable interface. As we discussed earlier, serialization allows us to convert the state of an object into a byte stream. This byte stream does not contain the actual code.

What is deserialization in Java?

The reverse operation of serialization is called deserialization where byte-stream is converted into an object. The serialization and deserialization process is platform-independent, it means you can serialize an object on one platform and deserialize it on a different platform.

How does Java serialization work?

Java serialization uses reflection to scrape all necessary data from the object's fields, including private and final fields. If a field contains an object, that object is serialized recursively. Even though you might have getters and setters, these functions are not used when serializing an object in Java.

Customizing Serialization and Deserialization With writeObject and readObject Methods

The JVM has full control for serializing the object in the default serialization process, but there are lots of downsides to using the default serialization process, some of which are:

It cannot handle the serialization of fields that are not serializable.

Deserialization process does not invoke constructors while creating the object so it can not call the initialization logic provided by the constructor.

How does Java deserialization work?

When deserializing a byte stream back to an object it does not use the constructor. It simply creates an empty object and uses reflection to write the data to the fields. Just like with serialization, private and final fields are also included.

Explaining Java deserialize vulnerabilities

A Java deserialize vulnerability is a security vulnerability that occurs when a malicious user tries to insert a modified serialized object into the system in order to compromise the system or its data. Think of an arbitrary code execution vulnerability that can be triggered when deserializing a serialized object. To better explain Java deserialize vulnerabilities, we first need to explore how deserialization works in Java.

A serialized object in Java is a byte array with state information. It contains the name of the object it refers to and the data of the field. If you look at a stored serialized object with a hex-editor, you can enclose and manipulate the information quickly.

For example, in July this year, a critical vulnerability (CVE-2021-35464) in ForgeRock's OpenAM stemmed from unsafe Java deserialization in the Jato framework used by the application. Through a simple GET request, an attacker could send a crafted serialized object to the server and execute their malicious code.

More recently, Atlassian began emailing enterprise customers to patch a critical JIRA Data Center vulnerability, CVE-2020-36239, that could let remote attackers execute arbitrary code on vulnerable servers. The cause of the vulnerability? Unsafe deserialization and exposed ports. An attacker could send crafted payload to the exposed Ehcache RMI network service ports 40001 and potentially 40011 and achieve code execution.