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

11–20 of 157 posts

Re: Oracle plans to dump risky Java serialization

#11

Post by bitmapbrother »

gmueckl wrote: post #10

I would hate to see serialization go completely. It has its uses. Maybe Java should copy the attributes that the C# data contract serializer uses to mark the subset of classes that may appear in serialized form. It coukd be retrofitted and would be a less drastic change at the same time.

Is it really going away, though? The article mentions that it's just being replaced with a safer implementation.

Re: Oracle plans to dump risky Java serialization

#13

Post by gmueckl »

bitmapbrother wrote: post #11
gmueckl wrote: post #10

I would hate to see serialization go completely. It has its uses. Maybe Java should copy the attributes that the C# data contract serializer uses to mark the subset of classes that may appear in serialized form. It coukd be retrofitted and would be a less drastic change at the same time.

Is it really going away, though? The article mentions that it's just being replaced with a safer implementation.

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.

Re: Oracle plans to dump risky Java serialization

#14

Post by blattimwind »

jeffdavis wrote: post #12

Can someone briefly explain the problems and how general they are to other serialization interfaces?

Many runtimes include object serialization capabilities, which allow serialization of essentially arbitrary object structures with little code. Unpacking that kind of structure always means that you're constructing object instances of potentially any object you can construct, which generally means you can run arbitrary code.

Examples: Java Serialization, Python marshal and pickle, Ruby marshal, Perl Data::Dumper.

Re: Oracle plans to dump risky Java serialization

#15

Post by tannhaeuser »

gmueckl wrote: post #10

I would hate to see serialization go completely. It has its uses. Maybe Java should copy the attributes that the C# data contract serializer uses to mark the subset of classes that may appear in serialized form. It coukd be retrofitted and would be a less drastic change at the same time.

Java has had the "transient" keyword for that since 1.0.

Re: Oracle plans to dump risky Java serialization

#16

Post by bonzini »

_0w8t wrote: post #4
hprotagonist wrote: post #2

cool. can we kill pickle next?

One of the attack vector in Java was classes storing native pointers as integer fields calling free on the above pointers in the finalizer. So the moment one can force deserialiazation of such classes one ends up with corrupted heap and trivially weponized exploits. Does pickle in Python suffer from the same problem?

Why the heck are those classes marked as `implements Serializable`?...

Re: Oracle plans to dump risky Java serialization

#17

Post by foob »

jeffdavis wrote: post #12

Can someone briefly explain the problems and how general they are to other serialization interfaces?

Here's an article which explains in detail how pickles/serialization work in Python, and how pickles can be constructed to evaluate malicious code when they are deserialized. That's specifically about Python, but the same issue exists in many other languages.

[1] - https://intoli.com/blog/dangerous-pickles/

Re: Oracle plans to dump risky Java serialization

#18

Post by crooked-v »

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

Coming from a Javascript context, would this be something roughly analogous to expecting JSON.parse and actually getting eval?

Re: Oracle plans to dump risky Java serialization

#19

Post by mbfg »

jeffdavis wrote: post #12

Can someone briefly explain the problems and how general they are to other serialization interfaces?

The problems is, any class (that's serializable) that is on the target machine's classpath, can be used as a serializable object. So if i want to screw with a server, i can create a payload with any of those classes, and send it to the server. The server will load that class when it sees it in the payload, and will execute code any code in the classes static initializer, before trying to instantiate an object. All of this happens before the host application regains control of the serialization, and realizes that the objects it's deserializing is not what it expects to be sent. So there have been a bunch of problems where classes no one expected to be used in serialization to be exploited because it's really simple for a class to marked serializable thru inheritance (be it class or interface).

Re: Oracle plans to dump risky Java serialization

#20

Post by bitL »

icebraining wrote: post #7
_0w8t wrote: post #4

Earlier quoted context omitted.

One of the attack vector in Java was classes storing native pointers as integer fields calling free on the above pointers in the finalizer. So the moment one can force deserialiazation of such classes one ends up with corrupted heap and trivially weponized exploits. Does pickle in Python suffer from the same problem?

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.
Post reply on HN