cool. can we kill pickle next?
Pickle is an entirely reasonable way to move data between processes when you're using Python for distributed processing.
Oracle plans to dump risky Java serialization
31–40 of 157 posts
Re: Oracle plans to dump risky Java serialization
#32In case anybody is wondering, this is the attack vector that was used for the equifax hack and is also used in a fair number of remote code execution exploits for java servers.
Re: Oracle plans to dump risky Java serialization
#33Earlier quoted context omitted.
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?
This is a key point. The problem is significantly worse because of Java's "everything is an object" philosophy. In languages where data is just data and not a combination of data and behavior, you don't get this kind of problem.
Re: Oracle plans to dump risky Java serialization
#34Re: Oracle plans to dump risky Java serialization
#35Earlier quoted context omitted.
So the problems don't apply to, say, rust because rust doesn't run arbitrary initialization when building structures?
This is a key point. The problem is significantly worse because of Java's "everything is an object" philosophy. In languages where data is just data and not a combination of data and behavior, you don't get this kind of problem.
You also don't get this behavior if you restrict the scope of serialization. The problem here was that Java wanted to make virtually any object potentially serializable. This required all sorts of deep hacks that circumvent various language guarantees and open the door to vulnerabilities (as well as encumber new features, as serialization could interact with anything). A new serialization mechanism would be restricted to classes for which serialization makes sense, basically classes that, as you say, represent data rather than data with complex behavior.
Re: Oracle plans to dump risky Java serialization
#36Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?
Re: Oracle plans to dump risky Java serialization
#37I 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...
Re: Oracle plans to dump risky Java serialization
#38It'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.
Re: Oracle plans to dump risky Java serialization
#39Won'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.
Re: Oracle plans to dump risky Java serialization
#40In theory this can be solved by using a security policy, but I don't think most are doing anything like that for deserialization.