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

61–70 of 157 posts

Re: Oracle plans to dump risky Java serialization

#61

Post by koolba »

mbfg wrote: post #52

all web applications use serialization to do session replication. Now this is safe as the both stream ends are controlled by the developer, and only if they are stupid, (instead of malicious) will there problems. Still if java serialization goes away, this will be the most widespread impacting change in the java ecosphere wrt changing how serialization works.

Using java serialization for sessions is terrible idea. It’s mildy convenient to start but bites you as soon as you want anything non-java to be able to read your session store.

Re: Oracle plans to dump risky Java serialization

#62

Post by erik_seaberg »

yzmtf2008 wrote: post #44
zeroxfe wrote: post #39

Earlier quoted context omitted.

AFAIK, Hadoop uses protocol buffers for message passing, not Java serialization.

Hadoop uses Avro actually, but the point still stands :)

Hadoop expects your keys and values to implement Writable and serialize themselves (a lot of these are actually hand-written expecting the instance to get reused for each input tuple). There's optional and fairly clumsy glue that makes Avro work in a key or value.

Re: Oracle plans to dump risky Java serialization

#63

Post by Const-me »

dwaite wrote: post #56
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...

I'm rusty on C#, but I believe the equivalent would probably be [Serializable] types being read from a Stream using a BinaryFormatter or SoapFormatter. A malicious stream could include any known types in the system marked as [Serializable], and as they are deserialized any associated static constructor/no argument constructor/property setters could be called. In the JSON case linked, I presume there is a root type gi…

They moved away from that. Many newer parts of the .NET framework (e.g. SOAP 1.2 implementation in WCF) use data contract serializers by default. With them, a complete list of known types must be provided to deserializer, it's typically done with [KnownType] attribute.

Re: Oracle plans to dump risky Java serialization

#65

Post by xenadu02 »

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

This is the entire point of NSSecureCoding as well. You must provide the list of allowed types and any unexpected ones trigger errors.

Re: Oracle plans to dump risky Java serialization

#66

Post by spockz »

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.

Don’t forget Kryo[1]. Also Avrò messages can contain the schema.

[1]: https://github.com/EsotericSoftware/kryo

Re: Oracle plans to dump risky Java serialization

#67

Post by kibibu »

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.

Re: Oracle plans to dump risky Java serialization

#68

Post by rad_gruchalski »

spockz wrote: post #66
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.

Don’t forget Kryo[1]. Also Avrò messages can contain the schema. [1]: https://github.com/EsotericSoftware/kryo

Yes! But Kryo docs explicitly mentions some things may have to be handled via Java serialization.

Re: Oracle plans to dump risky Java serialization

#69

Post by gmueckl »

bitmapbrother wrote: post #27
gmueckl wrote: post #13

Earlier quoted context omitted.

I may be wrong, but to me it seems like they will replace the current implementation with something fundamentally incompatible. My impression is that dependencies like RMI will go away, too. But that would be a huge breaking change.

Sure it's going to be incompatible and break old code. The title, however, makes it seem like Oracle is getting rid of serialization when it's just replacing it with a safer method.

Just for the sake of arguing semantics: "Just replacing" is incorrect in my view. The new implementation is designed specifically to not be one. It is a different mechanism mit a different interface and a different design goal.

Re: Oracle plans to dump risky Java serialization

#70

Post by rukuu001 »

paulddraper wrote: post #38
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.

And even more seamless...protobuf.

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