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

21–30 of 157 posts

Re: Oracle plans to dump risky Java serialization

#21

Post by jeffdavis »

blattimwind wrote: post #14
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.

So the problems don't apply to, say, rust because rust doesn't run arbitrary initialization when building structures?

Re: Oracle plans to dump risky Java serialization

#22

Post by teraflop »

crooked-v wrote: post #18
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?

Pretty much. It's slightly less terrible than that -- the deserializer doesn't evaluate arbitrary Java expressions, but it can call no-argument constructors, run deserializer methods, and set field values (including private fields) on any loaded class that's marked Serializable.

As you can imagine, any sufficiently large codebase is likely to have a million different ways this can be leveraged to get arbitrary code execution.

Re: Oracle plans to dump risky Java serialization

#23

Post by the_new_guy_29 »

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/

Thx fpr the good read

Re: Oracle plans to dump risky Java serialization

#24

Post by askvictor »

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

Might catch some cases, but just from a couple of weeks ago, by an org that supposedly puts security very high up the priority list we had this: https://news.ycombinator.com/item?id=17096022 (Signal's security hole created by using dangerouslySetInnerHTML)

Re: Oracle plans to dump risky Java serialization

#25

Post by ta5244626777 »

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

Yes it was a nice/quick/dirty way to persist an object graph, I bet it's been abused richly in a lot of codebases out there, it'll be curious to see how this is handled in terms of breakage i.e. the JDK that introduces this might be the Python 2/3 showdown (if that's still a thing).

Be curious to do a Github wide grep for ObjectOutputStream or something similar and see what it's like in open source land.

Re: Oracle plans to dump risky Java serialization

#27

Post by bitmapbrother »

gmueckl wrote: post #13
bitmapbrother wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: Oracle plans to dump risky Java serialization

#28

Post by pvg »

tannhaeuser wrote: post #15
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.

It also didn't have serialization in 1.0 neatly avoiding the entire problem.

Re: Oracle plans to dump risky Java serialization

#29

Post by chii »

mbfg wrote: post #19
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…

> create a payload with any of those classes, and send it to the server.

But on a deeper level, if a programmer doesn't know anything about security, then this sort of hole will continue to happen even if java serialization is disabled (just a bit harder to screw up). I m not that big of a fan of making security decisions without programmer's input, since you'd assume a professional programmer should know better anyway.

Re: Oracle plans to dump risky Java serialization

#30

Post by joshuamorton »

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.

Deserialization in Java requires reflection, which puts you firmly in the land of "I'm basically interpreted now". Javas serialization has basically the same set of vulnerability.
Post reply on HN