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

81–90 of 157 posts

Re: Oracle plans to dump risky Java serialization

#81

Post by Scea91 »

slaymaker1907 wrote: post #43
sewercake wrote: post #36

Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?

Spark uses its own serialization system which while similar to the built in serialization, is designed to give much better performance.

Only partly. Spark's RDD API which is still used quite heavily requires external serializer. Most of the time you would use Kryo, but it does not fork for objects larger than 2 GB or sometimes for custom classes that are not explicitly registered as Kryo serializable.

In these cases, the changes would break existing code. However, who knows when will Oracle decide to remove the Java serialization API. I expect it will take a few years and the situation will be different on the Spark side then.

Re: Oracle plans to dump risky Java serialization

#82

Post by icebraining »

bitL wrote: post #20
icebraining wrote: post #7

Earlier quoted context omitted.

Arbitrary code execution: https://www2.cs.uic.edu/~s/musings/pickle/

That only works because Python is an interpreter. Won't cause a thing on Java.

The JVM is a Java Bytecode interpreter; don't be so sure you can't make it run things.

Re: Oracle plans to dump risky Java serialization

#83

Post by _pmf_ »

benaadams wrote: post #74
scarface74 wrote: post #37

I was trying to understand if C# has the same issue. From what I can tell, as long as you use the default serialization, it seems to be safe. But I can't really tell. https://www.alphabot.com/security/blog/2017/net/How-to-confi...

There is a dangerous form https://docs.microsoft.com/en-us/dotnet/standard/serializati... > Binary serialization can be dangerous. Never deserialize data from an untrusted source and never round-trip serialized data to systems not under your control. The killed it in .NET Core 1.x; but brought it back in .NET Core 2.x due to back compat and interop complaints

> 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.

Re: Oracle plans to dump risky Java serialization

#84

Post by skocznymroczny »

echelon wrote: post #79
rukuu001 wrote: post #70

Earlier quoted context omitted.

Blushing because this is the first I've heard of it - I owe you one :)

Protos are amazing and have so many advantages over json. You'll love them!

Wouldn't they be a pain to debug, given that they are binary? I wouldn't want to use a hex editor to verify if my data serializes properly.

Re: Oracle plans to dump risky Java serialization

#85

Post by pure-awesome »

skocznymroczny wrote: post #84
echelon wrote: post #79

Earlier quoted context omitted.

Protos are amazing and have so many advantages over json. You'll love them!

Wouldn't they be a pain to debug, given that they are binary? I wouldn't want to use a hex editor to verify if my data serializes properly.

I am not sure, exactly what do you mean by "verifying" that your data serializes properly?

Do you mean that you don't trust the protobuf implementation itself to write the correct bytes, or are you worried you may have written the proto file wrong?

If it's the first case, protobuf is a widely used format that has been rigorously tested in the field. Provided you use it for a major language, you should be fine.

If it's the second case - could you not just serialize and then deserialize, and check that the objects that pop out again are the same as the ones that you sent in?

Re: Oracle plans to dump risky Java serialization

#86

Post by imtringued »

willvarfar wrote: post #76
kibibu wrote: post #67

Earlier quoted context omitted.

I suggest you look at the myriad security problems caused by Ruby's handling of YAML and JSON. It's not necessarily the serialization format at fault, but rather developer assumptions.

(Here's a post describing some of the problems back in the day with Ruby's YAML and JSON: https://williamedwardscoder.tumblr.com/post/43394068341/ruby... YAML is of course a format that is designed to instantiate objects as described in the source, rather than as checked by the destination, so I wouldn't want the world to adopt YAML instead of Java serialization.)

Yaml is primarily used as hierarchical config format because JSON and XML are too verbose for a human editor.

Re: Oracle plans to dump risky Java serialization

#88

Post by fnord123 »

rukuu001 wrote: post #26

It's less useful now than it used to be. In an age of ubiquitous JSON there's much less need for sending Java objects over the wire.

Schema migration in vanilla Java Serialization is a pita. It's absolutely an anti-pattern to use it at all, as far as I'm concerned. So this is all good news.

Re: Oracle plans to dump risky Java serialization

#89

Post by imtringued »

kgoutham93 wrote: post #47
sewercake wrote: post #36

Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?

I think wildfly also uses serialization to store session state when scaling horizontally.

The JPA spec requires entity IDs to be serializable and tomcat requires session variables to be serializable too.

This is going to break a lot of code.

Re: Oracle plans to dump risky Java serialization

#90

Post by MichaelMoser123 »

MichaelMoser123 wrote: post #75
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.

That would also kill RMI (at least JRMP), and that too would be a good thing, RMI doesn't even pass through a router (unless you do RMI-IIOP - and that is very different from regular RMI - JRMP) For java backwards compatibility used to be very important, so this is big news for the platform. I think this remoting the bytecode with serialisation madness was once upon a time very important part of RMI/serialisation - b…

Does not pass through firewall/NAT to be more specific
Post reply on HN