Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle plans to dump risky Java serialization

infoworld.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Oracle plans to dump risky Java serialization

#111

Post by dpark »

eicnix wrote: post #105
rad_gruchalski wrote: post #59

There are so many great alternatives available. It's a no-brainer. I applaud. [edit] so why the downvote? We have YAML, JSON, protobuf, Thrift, Avro. Yup, these serialize "contents" rather than "structure + contents" but one gets interop with other technologies for free. Every tech mentioned above is so simple to use that removing Java serialization is a no-brainer.

While using a general data transport format instead of Java object serialization is great for most applications it cannot replace all usecases. JVM based distributed grid computing services use Java object serialization to distribute queries throughout the grid. This allows users to write their queries as arbitrary Java code which will be executed on every node without having to deploy the code on every node.

How does that work? You describe a situation in which code that does not exist on a given node is executed on that node nonetheless.

Re: Oracle plans to dump risky Java serialization

#112

Post by quelltext »

quelltext wrote: post #108
Hupriene wrote: post #6

Having used java serialization a few times for POC level work, I'll be sorry to see it go. I wish they would just rename it something sufficiently ominous sounding that people wouldn't think about using it on untrusted data sources. Maybe AribitraryCodeAndDataSerialization

> Maybe AribitraryCodeAndDataSerialization Wait, what? Java serialization does not serialize and deserialize code. The only thing encoding behavior when serializing is class names. The receiving system needs to know those classes/be able to load them.

... unless you override Java's default serialization behavior and build a whole lot of black magic.

Apparently there are some vulnerabilities in the implementation, but they are not an inherent part of it as some people seem to think.

Re: Oracle plans to dump risky Java serialization

#113

Post by _pmf_ »

GordonS wrote: post #107
_pmf_ wrote: post #83

Earlier quoted context omitted.

> The killed it in .NET Core 1.x; but brought it back in .NET Core 2.x due to back compat and interop complaints I've been using .NET binary serialization for dirt cheap local snapshots for the purpose of undo/redo. It's perfect for this.

There are plenty of other options though, such as JSON, MessagePack, Protocol Buffers etc. And BinaryFormatter has always performed poorly against 3rd party libs, especially other binary formatters such MessagePack

Do any of these options support proper handling of cycles in the object graph out of the box?

Re: Oracle plans to dump risky Java serialization

#114

Post by eicnix »

dpark wrote: post #111
eicnix wrote: post #105

Earlier quoted context omitted.

While using a general data transport format instead of Java object serialization is great for most applications it cannot replace all usecases. JVM based distributed grid computing services use Java object serialization to distribute queries throughout the grid. This allows users to write their queries as arbitrary Java code which will be executed on every node without having to deploy the code on every node.

How does that work? You describe a situation in which code that does not exist on a given node is executed on that node nonetheless.

You write a query that is wrapped inside a serializable object. The object with your code inside is serialized using Java object serialization and distributed to every node. Each node is now able to execute your query based on Java code.

https://ignite.apache.org/features/computegrid.html

Re: Oracle plans to dump risky Java serialization

#115

Post by dnomad »

xg15 wrote: post #104

I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize how enormously dangerous it is.

If you want data then define a schema and write/read your data. Serialization should really never be used and certainly not for long-lived data storage.

There is one place where serialization becomes useful and that is for storing objects off-heap, IPC, and for short-term storage (ie snapshots like Android's parcelable). For these cases I'd like to see the JVM embrace not just immutable value objects but full-fledged structs that have a well-defined memory layout. You can do this today using off-heap Buffers and interfaces but language support is always good so there's a universal standard that everybody can build upon. Once that's in place there'd be no need to ever use serialization.

That said I can't imagine Oracle will simply remove support object serialization. It may be kicked out of the "core" JDK and become an optional module. The classes may be deprecated. But the functionality likely isn't going anywhere in the next ten years.

Even if they did remove it nobody should be using the standard object serialization anyways. If you're going to use serialization (and you shouldn't) then you should absolutely be using FST [0].

[0] https://github.com/RuedigerMoeller/fast-serialization

Re: Oracle plans to dump risky Java serialization

#116

Post by AsyncAwait »

dnomad wrote: post #115
xg15 wrote: post #104

I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…

> Code is not data

Lisp would, of course, disagree. :-)

Re: Oracle plans to dump risky Java serialization

#117

Post by jnwatson »

adrianmsmith wrote: post #77
ataturk wrote: post #3

It's funny that serialization is noted as a "horrible mistake" from 1997 but no mention of RMI, the even worse mistake. I guess Java has a lot of bad mistakes. I wish Oracle would end Java so I could move on to something else. Or maybe I'll just move on to something else anyways as I'm really rather sick of writing these syntactically crippled lambdas. The streaming stuff is almost good.

Could you point me to some information on why RMI is a bad mistake? (Genuine question.)

RMI (and similar technologies like CORBA) is a “mistake” in today’s world because it makes every public method an attack surface. It also hides important details that the client really can’t not deal with, namely network issues.

I put mistake in quotes because there are situations where RMI (and Java serialization) work fine: trusted, reliable networks like cluster or grid computing.

Re: Oracle plans to dump risky Java serialization

#118

Post by dnomad »

dnomad wrote: post #115
xg15 wrote: post #104

I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…

BTW, contrary to other comments this has nothing to do with the binary nature of serialization. The problem is that serialized "data" are programs. They're code. For some really scary stuff see the XMLDecoder [0] API which is XML-based " Java-bean serialization" but actually enables arbitrary code execution.

Note that even when it's not an explicit feature serialization libraries have a tendency to become unexpectedly Turing-complete [1]. There are many, many systems out there that are vulnerable to "surprise Turing" attacks.

The only real defense against this is to have well-documented schemas in place and to thoroughly validate all incoming data. Ironically all the guys churning out schema-less JSON microservices think they're okay. They're not. As they say the truth is even worse than it appears...

[0] http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execut...

[1] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...

Re: Oracle plans to dump risky Java serialization

#119

Post by resource0x »

dnomad wrote: post #115
xg15 wrote: post #104

I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…

There's no such thing as "data". Every piece of "data" eventually gets interpreted, thus becoming a "command" in some level of abstraction. The core of every security vulnerability is the belief that "this is just a piece of data".

Re: Oracle plans to dump risky Java serialization

#120

Post by marcodave »

dnomad wrote: post #115
xg15 wrote: post #104

I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…

There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…

> serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do.

As I recall, the default behavior of Java (de)serializer, would only write the data fields one by one in binary format. The code itself, i.e. the bytecode of the methods and the class definition itself have to be in the classpath at application startup, so how could this malign code be injected as part of the attack?

Post reply on HN