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

101–110 of 157 posts

Re: Oracle plans to dump risky Java serialization

#101

Post by tiraniddo »

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

Yes it’s just as vulnerable (example [1]), but I think .net serialization is exposed less often to untrusted inputs than Java with its myriad of enterprise software.

[1] https://googleprojectzero.blogspot.co.uk/2017/04/exploiting-...

Full disclosure, I’m the author of that blog post.

Re: Oracle plans to dump risky Java serialization

#103

Post by willtim »

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

In OOP, objects have identity and state, having a remote endpoint with both these attributes is undesirable. IIRC, RMI also encourages one to abstract over the network, which can lead to very fine-grained, brittle and possibly insecure communication. This is somewhat ironic given that Sun itself authored "The fallacies of distributed computing".

Re: Oracle plans to dump risky Java serialization

#104

Post by xg15 »

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 classes. If only one class is not available or has breaking changes, there is no (built-in) way to access anything inside the blob.

This is particularly fun if you want to refactor things. Suddenly package names, class names and names of private fields (!) are part of your public interface.

So if we could drop reflection/unsafe-based serialization and instead just got a simple parser/writer for java's binary object graph format, I'd be very happy.

Re: Oracle plans to dump risky Java serialization

#105

Post by eicnix »

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.

Re: Oracle plans to dump risky Java serialization

#106

Post by jwilk »

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

Archived copy that can be read without JS enabled:

https://archive.is/2JGiJ

Re: Oracle plans to dump risky Java serialization

#107

Post by GordonS »

_pmf_ wrote: post #83
benaadams wrote: post #74

Earlier quoted context omitted.

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.

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

Re: Oracle plans to dump risky Java serialization

#108

Post by quelltext »

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.

Re: Oracle plans to dump risky Java serialization

#109

Post by jwilk »

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

> Only it then turns out that the Ruby JSON parser … yes, you’ve guessed it … the Ruby JSON parser can instantiate complex objects too.

Huh. Where can I read more about this?

Re: Oracle plans to dump risky Java serialization

#110

Post by jwilk »

kibibu wrote: post #67
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.

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.

Regarding YAML, it's not just Ruby:

* Python's yaml.load() hapilly executes arbitrary code.

* Some Perl YAML libraries deserialize objects by default:

http://blogs.perl.org/users/tinita/2018/02/safely-load-untru...

Post reply on HN