Recently, Oracle has been thinking about dropping the support of the data serialization/deserialization support from the Java’s main body. This statement is from the chief architect of Java platform group at Oracle – Mark Reinhold.
For most of those who didn’t know about Java serialization process, it’s a method that takes a data object and transforms it into a stream of bytes in binary format. When it’s transported across networks or saved within a database, it becomes deserialized and gets back into its original form.
This method is really convenient for programs and is available as a feature on lots of high-level programming languages. However, it’s always a headache for Java as it’s the constant stream of security flaws – one after another.
Serialization – a horrible mistake
Reinhold also added that adding the support of serialization in Java back in 1997 was a “horrible mistake”.
Reinhold also confirms that presently, Java team is working for dropping the support of serialization from Java for good. However, in case developers need the feature, it will be available as a plugin system through a new framework. However, there’s no fixed, final date when the support is going to drop from Java.
Until Oracle makes the final move, project leads and companies not willing to have that serialization/deserialization rogue module can take the advantage of “serialization filter” that will disable the operation of serialization altogether.
The security problems
The issue of serialization attacks is known to the community for years. However, the biggest commotion it made was in early 2015 when 2 security researchers – Gabriel Lawrence and Chris Fronhoff were able to find out a deserialization flaw in a really popular Java application – Apache Commons Collection.
In late 2015, researchers from Foxglove Security expanded on the vulnerability and explained in details how an attacker can take the advantage of it. Their experiments proved that an attacker would be successful in uploading malicious data inside popular Java apps like Jenkins, OpenNMS, JBoss, WebLogic, WebSphere etc.
Using this vulnerability, the malicious data could be serialized and stored in a database or in the system’s memory. When deserialized, it would allow the malicious code to run alongside other codes. This flaw was prevalent in the Java ecosystem in 2016. As a result, a number of major vendors issued updates for their systems. The vendors include Adobe, Intel, VMware, HP, SolarWinds, Apache, Cisco, Jenkins etc.
The flaw was so dangerous that Google ultimately decided to ban it altogether in their free time and patched over 2600 projects.
Serialization is a big bug for Java
Reinhold said that the process of data serialization itself can be held responsible for about a third or even half of all the known Java flaws.
This assessment holds mostly correct. As an example, during the security updates of January 2018, Oracle patched nearly 230+ vulnerabilities. More than 25% of those were related to deserialization operations.
However, while serialization is becoming a taboo in Java, there are other programming languages like Ruby, .NET etc.
