In the blog post "Using Google's Protocol Buffers with Java," I quoted Josh Bloch's Third Edition of Effective Java, in which he wrote, "There is no reason to use Java serialization in any new system you write." Bloch recommends using "cross-platform structured-data representations" instead of Java's deserialization. The proposed JDK 11 API documentation will include a much stronger statement about use of Java deserialization and this is briefly covered in this post.
The second draft of the "Java SE 11 (18.9) (JSR 384)" specification includes an "A2 Annex" called "API Specification differences" that includes the changes coming to the Javadoc-based documentation for package java.io. The new java.io package documentation will include this high-level warning comment:
Warning: Deserialization of untrusted data is inherently dangerous and should be avoided. Untrusted data should be carefully validated according to the "Serialization and Deserialization" section of the Secure Coding Guidelines for Java SE.
At the time of the writing of this post, the referenced Secure Coding Guidelines for Java SE states that it is currently Version 6.0 and was "Updated for Java SE 9."
The intended package-level documentation for package java.io in JDK 11 will also provide links to the following additional references (but likely to be JDK 11-based references):
- Java Object Serialization Specification (JDK 10 link)
- Serial Filtering best practices (JDK 10 link)
- serialver tool (JDK 10 link)
The former reference link to the "Java Object Serialization" (JDK 8) document will be removed from java.io's package documentation.
In addition to the java.io package documentation that is being updated in JDK 11 related to the dangers of Java deserialization, the java.io.Serializable interface's Javadoc comment is getting a similar high-level warning message.
These changes to the Javadoc-based documentation in JDK 11 are not surprising given various announcements over the past few years related to Java serialization and deserialization. "RFR 8197595: Serialization javadoc should link to security best practices" specifically spelled out the need to add this documentation. A recent InfoWorld article called "Oracle plans to dump risky Java serialization" and an ADT Magazine article called "Removing Serialization from Java Is a 'Long-Term Goal' at Oracle" quoted Mark Reinhold's statement at Devoxx UK 2018 that adding serialization to Java was a "horrible mistake in 1997."
There has been talk of removing Java serialization before, sometimes even in humor. JEP 187 (Serialization 2.0) has disappeared with barely a trace. JEP 154: Remove Serialization was created with the intent to "deprecate, disable, and ultimately remove the Java SE Platform's serialization facility." However, that JEP's status is now "Closed / Withdrawn" (April Fool's Day prank). Still, as talk of removing Java serialization picks up, it seems prudent to consider alternatives to Java serialization for all new systems, which is precisely what Bloch recommends in Effective Java's Third Edition. All this being stated, Apostolos Giannakidis has written in the blog post "Serialization is dead! Long live serialization!" that "deserialization vulnerabilities are not going away" because "Java's native serialization is not the only flawed serialization technology."
Additional References
- Java Object Serialization Specification
- JDK 10: Serialization Filtering
- Removing Serialization from Java Is a 'Long-Term Goal' at Oracle
- Serialization is dead! Long live serialization!
- A First Look Into Java’s New (and Flawed) Serialization Filtering
- The perils of Java deserialization
- Serialization is not Java's Heartbleed Bug
- Java Deserialization Security FAQ
- Surviving the Java Deserialization Apocalypse (OWASP AppSecEU 2016)
- CWE-502: Deserialization of Untrusted Data
1 comment:
"The State of Java Serialization" was recently published and describes the possibility of removing serialization from Java by making it a Jigsaw module that could be omitted from a deployed Java application when not used.
Post a Comment