51–60 of 157 posts
Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?
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.
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.
Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?
AFAIK, Hadoop uses protocol buffers for message passing, not Java serialization.
Edit, they switched to Protocol Buffers in 0.23
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...
In the JSON case linked, I presume there is a root type given when you are attempting to deserialize a document. However, if one of the properties of that type is ambiguous (say System.Object), and the deserialization algorithm looks for a 'type' property in the JSON with a class name to determine what is instantiated, then there can be all sorts of unintentional types that might be built by the processing of that malicious JSON.
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...
Json.NET seems to allow the same behavior, but has it disabled by default.
> In fact the only kind that is not vulnerable is the default: TypeNameHandling.None
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?
Why the heck are those classes marked as `implements Serializable`?...
[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.
Can someone briefly explain the problems and how general they are to other serialization interfaces?
This class of problems was very common when that serialization appeared in Java. It was possible to inject code into pretty much anything, e-mails (1), office documents (2), web pages. Since that time, most developers / managers have learned their lesson and started to pay attention / allocate resources so modern software/protocols/formats tend to be more secure, at least on average.