Slashdot Mirror
Oracle Calls Java Serialization 'A Horrible Mistake', Plans to Dump It (infoworld.com)
An anonymous reader quotes InfoWorld:
Oracle plans to drop from Java its serialization feature that has been a thorn in the side when it comes to security. Also known as Java object serialization, the feature is used for encoding objects into streams of bytes... Removing serialization is a long-term goal and is part of Project Amber, which is focused on productivity-oriented Java language features, says Mark Reinhold, chief architect of the Java platform group at Oracle.
To replace the current serialization technology, a small serialization framework would be placed in the platform once records, the Java version of data classes, are supported. The framework could support a graph of records, and developers could plug in a serialization engine of their choice, supporting formats such as JSON or XML, enabling serialization of records in a safe way. But Reinhold cannot yet say which release of Java will have the records capability. Serialization was a "horrible mistake" made in 1997, Reinhold says. He estimates that at least a third -- maybe even half -- of Java vulnerabilities have involved serialization. Serialization overall is brittle but holds the appeal of being easy to use in simple use cases, Reinhold says.
To replace the current serialization technology, a small serialization framework would be placed in the platform once records, the Java version of data classes, are supported. The framework could support a graph of records, and developers could plug in a serialization engine of their choice, supporting formats such as JSON or XML, enabling serialization of records in a safe way. But Reinhold cannot yet say which release of Java will have the records capability. Serialization was a "horrible mistake" made in 1997, Reinhold says. He estimates that at least a third -- maybe even half -- of Java vulnerabilities have involved serialization. Serialization overall is brittle but holds the appeal of being easy to use in simple use cases, Reinhold says.
But the Java fanatics just put in more and more features, regardless of whether sane languages had them or not.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Regardless of language, object serialization is a dangerous idea. While it may seem like a nice idea at first, loading objects from unverified mutable data is an invitation for someone to tinker with that data. The situation only gets worse when your object structure changes because now your object data is invalid or incomplete.
Much like goto, I'm not arguing that it's not useful but rather that it's use it is inherently dangerous.
Anons need not reply. Questions end with a question mark.
Why would serialization be a security risk?
Hu? Cant ... you write to a disk or to a socket and thats it.
Sure, I'm nitpicking, because deserialization might be a security risk.
However only if you actually do it and e.g. leave open paths how bad files can end on your disk, which you then read, or open a socket and accept incoming serialized objects.
A typical Java program is absolutely not vulnerable to anything regarding serialization unless the programmer (intentionally?) made it so.
Articles about this (and basically every post here in the story while I type this): are simply wrong.
Java Serialization was once its strongest point of success. Many GUI builders let you edit "beans" and simply serialize the GUI as an graph of objects that simply gets read in again when the application starts and you call the setVisible(true) method to show your window.
Not needing to write any boilerplate code for writing and reading objects is a huge time saver and simplification.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
To answer your points with the obvious:
1) Use the validation supported by java, just like you would in XML, JSON, . Problem solved. Serialization isn't the issue here, the app dev is. The app dev can be lazy on XML or any other serialization classes.
2) Same as point 1. The facility is there, use it. 'off by default' isn't an excuse for it being 'bad'
3) Unit tests and write proper code. Again, this problem isn't different to any other XML/JSON serialisation mechanism.
4) You have the same issue with any XML classes if you're using opensource code, JSON, etc, etc.
So, basically, the issues are the same for any serialization classes, the java ones aren't any different to be honest.
If I'm following you correctly, the problem isn't serialization per se but rather the fact that the deserialization is being done by the Java runtime (which has no way to validate the resulting objects against the application's requirements, since its deserialization code is application-independent, and also has the power to instantiate any kind of object, even those that are totally irrelevant to the task at hand), rather than by the application itself.
A user-supplied deserialization-routine, OTOH, has at least a chance of being secure in the face of invalid source data, since it can check to make sure that its constraints are correctly satisfied and reject the data if they aren't.
Of course, avoiding making every application developer write his own application-specific serialization/deserialization routines was largely the point of this Java feature, but in hindsight it appears that was a bad decision.
I don't care if it's 90,000 hectares. That lake was not my doing.
Serialization isn't inherently bad. It's bad practices and misuse, which won't change. It'll just be replaced by many developers with XML, JSON, Protobuf, YAML, or other. Then, someone will inevitably sprinkle on some reflection or code generation, and you've almost done a 360... but with a lot more code and even more that could go wrong. I don't agree that adding more training wheels and/or removing features is always the best way to fix bad developer habits.