Live data from Hacker News

Oracle plans to dump risky Java serialization

infoworld.com

1–10 of 157 posts

Re: Oracle plans to dump risky Java serialization

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

Re: Oracle plans to dump risky Java serialization

#4

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?

Re: Oracle plans to dump risky Java serialization

#5
post #4

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?

well theres this comment in the docs:

> Warning

> The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.

Re: Oracle plans to dump risky Java serialization

#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

Re: Oracle plans to dump risky Java serialization

#7
post #4

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?

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

Re: Oracle plans to dump risky Java serialization

#9
post #4

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?

The primary difference between pickle and all the other problematic serialization mechanisms that have been causing security issues is that pickle has been labeled for decades now as being unsuitable for any use with public data. No sarcasm, I'm quite serious. It hasn't been 100% successful at preventing issues, there have been a couple, but it does seem to have been enough to keep it from being the star of it's own massive disaster, even though the potential is theoretically there.

As with many of the dynamic language deserializers, such as the Ruby YAML one, for pickle it's not even an exploit or something... it's a feature of the code that it can call methods, and getting to arbitrary methods isn't that hard.

Re: Oracle plans to dump risky Java serialization

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