Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Serialization Is Dead! Long Live Serialization!

DZone's Guide to

Serialization Is Dead! Long Live Serialization!

Oracle has declared an end to Java's serialization approach, but that's not the end of the story. Read on for a security researcher's thoughts.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Oracle has signaled there are big changes on the way for how Java handles serialized objects. Java Platform Chief Architect Mark Reinhold describes the decision in 1997 to adopt the current serialization feature as a "horrible mistake."

Reinhold also claims that as many as half of all Java vulnerabilities are linked to the current serialization approach. Still, Reinhold has not committed to a release schedule for replacing serialization.

Oracle's current plans are to create a new plugin mechanism that will allow developers to choose the serialization format of their choice. Supported formats will be XML, JSON, YAML, and even the existing, problematic native serialization. Additionally, a new, safe serialization format will be created that will be based on a new language feature called Data Classes, which is part of the project Amber.

There is little doubt that serialization issues plague Java and that addressing the underlying causes will benefit the Java community. But, how long will it take to bring a new approach to the market, and will simply replacing the old serialization mechanism with a new approach end the issue?

Here Are Our Thoughts:

  1. Removing the existing serialization mechanism is a long-term goal. Oracle will need a couple of years to achieve this. The current approach to serialization is two decades old and is the foundation of hundreds of Java SE components. Even when an alternative approach becomes available, Oracle will likely keep native serialization as an option just to maintain backward compatibility for a few more years.
  2. Enterprise middleware, servers, and higher level protocols (such as RMI, JMX, JMS, etc.) depend on Java's native serialization, and, as such, are very difficult to change. Software vendors will need time and effort - possibly years - to switch to an alternative technology. Backward compatibility will be a big issue here as well.
  3. Even if all the above issues are resolved, deserialization vulnerabilities are not going away. Java's native serialization is not the only flawed serialization technology. XML and JSON deserialization vulnerabilities exist and are real threats to enterprises. In the recent months, attackers exploited these vulnerabilities (such as CVE-2017-9805) to infect their targets with crypto-mining malware.
  4. Legacy servers and apps will remain vulnerable. It is difficult now for most organizations to keep pace with Java updates. Oracle's Co-CEO Mark Hurd recently acknowledged that Java users typically run months to years behind in patching. Upgrading versions or rewriting apps takes even longer, if practical.
  5. Organizations should still worry about deserialization issues because Java is not the only platform that is affected. .NET, Ruby, PHP, Python, and others are also affected by deserialization vulnerabilities.

Java remains, by a wide margin, the most popular platform language in the world. Any effort to improve Java operations will be a welcome one.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,java security ,deserialization ,serialization

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}