Oracle has declared an end to Java’s serialization approach, but that’s not the end of the story. Java Platform Chief Architect Mark Reinhold claims that as many as half of all Java vulnerabilities are linked to the current serialization approach.
Oracle has declared an end to Java’s serialization approach, but that’s not the end of the story.
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:
- 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 backwards compatibility for a few more years.
- 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 any alternative technology. Backwards compatibility will be a big issue here as well.
- 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 with crypto-mining malware their targets.
- 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.
- 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.