Waratek's Giannakidis: Removing Serialization from Java Is Not the End of the Story

Last month, Oracle's chief architect, Mark Reinhold, said during a conference Q&A that one of Oracle's long-term goals is to change the way Java handles object serialization. In fact, he called the decision to adopt the current serialization feature a "horrible mistake," and a virtually endless source of security vulnerabilities.

Java object serialization is the process of converting an object into a stream of bytes for transport and storage. Oracle is currently planning to develop a plugin mechanism that will allow developers to choose a serialization format, such as XML, JSON, YAML. They'll also be able to choose the existing native serialization. Oracle says it is also developing a new, safe serialization format based on a new language feature called data classes, which is part of the project Amber.

Removing serialization is one of the goals of Project Amber, an OpenJDK project that aims to "explore and incubate smaller, productivity-oriented Java language features that have been accepted as candidate JEPs under the OpenJDK JEP process," the project page explains, including lambda leftovers, pattern matching, local-variable syntax for lambda parameters, switch expressions, and raw string literals. Announced last year, the project is being led by Oracle's rockstar Java architect Brian Goetz. He discusses his ideas around "the possible direction of data classes in a blog post.

Apostolos Giannakidis, security analyst at Waratek, a Dublin-based app security tools provider with a special focus on Java, is one of my go-to Java security experts. He does work for a security products vendor, but his insights are always spot on. He shared his thoughts on these long-time-coming changes in a recent blog post, with the subtitle "Oracle has declared an end to Java's serialization approach, but that's not the end of the story."

"There is little doubt that serialization issues plague Java and that addressing the underlying causes will benefit the Java community," Giannakidis wrote. "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?"

Among his concerns: removing the existing serialization mechanism will take at least a couple of years. "The current approach to serialization is two decades old and is the foundation of hundreds of Java SE components," he wrote. "Even when an alternative approach becomes available, Oracle will likely keep native serialization as an option just to maintain backwards compatibility for a few more years."

He also worries that enterprise middleware, servers, and higher-level protocols (such as RMI, JMX, JMS, etc.), which depend on Java's native serialization, are going to be very difficult to change. Software vendors might need years to switch to any alternative technology. And backwards compatibility will be a big issue.

"Even if all the above issues are resolved, deserialization vulnerabilities are not going away," he wrote. "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 with crypto-mining malware their targets."

While Oracle gets its arms around its serialization-removal plan, legacy servers and applications will continue to be vulnerable, Giannakidis warned. "It is difficult now for most organizations to keep pace with Java updates," he wrote. "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.

He also warned that non-Java shops should be worried about deserialization issues, because Java isn't the only platform affected by it. .NET, Ruby, PHP, Python, and others are all subject to deserialization vulnerabilities.

Posted by John K. Waters on June 11, 2018