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.
What is this thing called a "record"? What possible use is it? Or could it be a new name for an old concept that might have existed in some ancient cruddy languages. Cobol anyone?
Java developers now have to wipe their own ass.
So they are replacing efficient binary serialization with serialization in textual form, and that's somehow better?
(FYI: If you can't figure it out from the context given in the summary, then maybe you're not the intended audience.)
The summary tells us that records are a planned feature that doesn't exist yet, but that records will be the plain-old-data (aka PoD) replacement for full object serialization.
Back in the day your options of serializing objects was Corba more or less.
Having serialization built into the language and having remote method invocation (RMI) immediately accessible was a game changer for project design and implementation between different processes and machines.
I'm not sure what went wrong, was it implementation issues or bad API decisions that cause security issues, I'm curious to hear. The bottom line is that these features were a gold mine back then.
whoooosh
https://en.wikipedia.org/wiki/... ?
I've not found the JSON's serialization.
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.
I mean how obvious are we talking? Like can we get Giuliani out here again to just blurt out smoking guns like bourbon burps?
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.
OK I don't get it. Serialization is just saving the field values to a file and then reading it back. Of course if you just read a file without any validation and you don't know if it has been tampered with then of course you can have security issues. But this applies to any file formats or data anywhere. Java serialization is not a unique case. Serialization is an easy way to load values without going through an intermediary format. Replacing it with JSON or XML doesn't change the issue one bit.
1. No validation. You might have a nicely designed object, well tested, and has all sorts of validation checks to ensure that the internal state is never broken. Java object serialization bypasses all validation, permitting an attacker to construct a malformed object. Exactly how that would cause a problem requires a bit more work on the attacker's part, by studying how the application reacts to the malformed object. Adding validation is supported with Java serialization, but its not used by default. The designers favored simplicity over safety. Does switching to JSON magically fix the validation problem? Nope.
2. Loading of classes that you didn't expect to load. If I expect to receive a serialized list of strings, there's nothing to prevent an attacker to providing a list of any kind of object instead, due to type erasure. The application might fail to process the list because of a ClassCastException, but the potential damage is done. Java serialization /does/ support filtering out classes that aren't expected, but this is off by default. You need to define the blacklist yourself. Why is loading other classes a problem? See the next reasons:
3. Custom code during deserialization, which is actually necessary for performing your own validation. You can define your own code which runs when the object is deserialized, and the code can do pretty much anything. An attacker might be able to trick the code (using malformed input) into doing something harmful.
4. Additional classes on the classpath. Even if all of your code is well behaved, and has proper validation checks, and proper custom code, you're still vulnerable because additional classes exist that you're not aware of. You had no idea that there's this class 'Q' which has broken custom code, because Q was sucked in as a dependency of something else. That popular open source library you're using might be exposing your application to attack, and you didn't even know it.
For anyone designing an object serialization mechanism, always consider the tradeoffs when trying to make the system easier to use. Always use whitelists for trusted code instead of blacklists. Always construct objects using the object's public API. Favor the use of standard representations (maps, lists, tuples) instead of supporting full-blown customization. A little bit of friction can be a good thing.
What the fuck is going on?
Oracle thinks opening up future feature requests (does it really need any more?) to a public voting system (so any retard with an Internet connection can have an influence over the future of Java) and moving to a six month release cycle (how fucking much are you planning on changing the language to a need a fucking six month release cycle?) and fucking JEP 286 (yay, let's make Java like JavaScript!) is a good idea, but object serialization needs to go?
C is starting to look really good to me lately.
While I've dabbled in several other language, Java has 'paid my bills' for most of the last twenty years, so my view may be slanted. However, I can say that I've never written nor encountered a 'buffer overflow' hidden away in any code I was directly responsible, and while there have been a few over the years in the core and some well used libraries, they have been usually related to Serialization. This is a good move.
I'd argue that Java is the reason why so many Linux servers are used in the corporate environment. The ability to write/compile software on typical Windows desktops (or Mac) yet run reliably on Linux has been a big selling point. In fact the only places I've worked at with significant Windows Server installations have been those who's product is built on dot net, C# or C++. While there are 'work arounds' (e.g. virtual box, Cygwin, etc) to test and compile many other languages in such an environment, few languages offer the same level of host OS diversity.
The force that blew the Big Bang continues to accelerate.
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.
There, I said it.
Yes, although technically you're talking about the portability of the Java VM rather than Java the language. The language I find adequate and mediocre, but I agree the VM and the "it just works" thing makes it compelling.
In some way, Java started as a toy language and headed downhill since. Multiple inheritance and deterministic object destruction are hard but useful. Java never had those, but it had an option to have full featured, grown up applications on desktop and in the web browser. Of course native look and feel of the former and security of the later is hard. So - out these features go. Couldn't make J2ME on mobile phones work either, so took another company to productize Java for mobile apps. Instead of appreciating the effort, Oracle has to take Google to court. Serialization is a solid server side feature, and I think that's the last use case of Java still supported by Oracle. If they can't make it work properly, what exactly is Java for?
for that? Still, If I coded a lot of Java I could see likeing object serialization. Being able to write out the state of your objects cuts down on the amount of custom save code you'd have to write.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I have never used this serialisation (under potentially dangerous conditions) or any other language feature not allowing me to have a reasonably good understanding of what is going on in the code. I also support any effort to reduce unnecessary functionalities from programming languages and, in general, to let them efficiently accomplish their expected goal. On other hand, some people might prefer to rely on certain features about which I don't care and their code might be as good as mine.
What I certainly don't support are the deflecting-responsibility-paternalistic-reaction attitudes which seem so common lately. Descriptive example:
- (developer wannabe) "My application has lots of security problems. The responsible is the language for allowing me to do what I shouldn't.".
- (paternalistic programming language) "You are right. We are aware that you might do really stupid things in case of being able to do so."
(further ridiculous, childish, amateur, tons-of-problems-prone, etc. nonsense...)
Don't you think that certain functionality in your programming language is worth keeping? Remove it! Do you usually have problems when relying on certain feature of a programming language for whatever reason? Don't use it! Or learn to use it properly! But what is with all these generic paternalistic behaviours lately? Making the overall programming experience more comfortable is certainly a good thing. Arbitrarily restricting the capabilities of programming languages (expected to be used by experts!) to somehow account for incompetence or lack of care is ridiculous. Over-protection is usually a very bad idea which provokes lower quality outputs (worse programmers) and other problems (false sense of security, disproportionate trust in what might be faulty, etc.).
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Object Serialization was horrible from day one. It was the tool of lazy programmers for years.
Performance wise it was a disaster. People would pass objects between jvm instances with no regard to the size of the data blob they were sending. When in reality very little of an object is required to be sent in most use cases. Example: When you have a java cluster and you sync session objects between instances. ( Note this is just dumb anyway. There are far better patterns for this. ) But your low cost developer is stuff the session object with literally everything they can think of for data. So you see these monster 20Meg Objects fly around. The bigger you cluster gets the SLOWER it becomes as all the object passing is just simply taking over all the processing and memory.
Security. Massive issue here with object deserialization. Basically you can sneak any payload in you want here. You may have had value checks on the set methods but the vast majority simply trust a deserialized object. Trivial to change a string value into a sql injection string. And a million other holes just like this one.
Object serialization means that the two ends of the object share must now be in LOCK step with each wr.t. to class signatures. Which means to upgrade them you have to bring both end down at the same time. In the case of web infrastructure you are now forced to take that service completely offline in most scenarios. And if you are using something like RMI to a back end. That now has to be upgraded as well. This makes change operations incredibly painful for no reason whatsoever.
Personally I like the use of protobuf as a means of passing object data around. It literally solves all of the above problems with very little overhead. And it has the added benefit of being compatible with many other languages. It's also far tighter than xml and end thus takes less to transmit. Where as XML tends to cause a temp object storm on the receiver as it is deserialized. Which in turn causes more expensive garbage collection cycles.
News at eleven!
This is not news, unless we've all turned our clocks back to 2016 See: https://dzone.com/articles/a-f... and http://openjdk.java.net/jeps/2...
Put a hash on it, have a checksum, and specific segments where only data can be retrieved. I'm surprised there isn't a generic data object where you could add data only versions and pass that into a pipeline to verify.
Why would you ever use eval in Ruby?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
EMP pulse, ATM machine, HIV virus, PIN number, MSDS sheet, NIC card, IRA account, ISBN number, LCD display, PDF format, SPF factor, AC current. English does this, deal with it.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
That is why, for real programmers, we have C++! Said bitching/whining remains as bitching/whining. See any /. article on C++ for an example.
Why are C++ programmers such douches?