41–50 of 157 posts
In 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.
Earlier quoted context omitted.
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 anyw…
Since there won’t be any code that gets executed, that particular vector is closed.
Of course if the code reading that object does something stupid…
Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?
Earlier quoted context omitted.
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 anyw…
Recent releases added an opt-in feature to filter which classes are allowed to be deserialized, but there's still a horrible amount of open, unauthenticated network ports that take in serialized java.
The programmer trying to get the same failures in a post-serialization world would presumably have to find or build a new system with the same design issues.
There are some valid uses for it, but the interface is unsafe by default. How about instead, requiring a MAC key in the serialization protocol?
This might be your approach if say your session cookie is based on serialized Java.
(However, most people give up on this approach - java serialization is also very inefficient space-wise, and the cookie will get too big for the browser to honor)
Won't this have serious implications for Spark, Hadoop, and other frameworks that distribute workloads across multiple JVM instances?
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.
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`?...
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.
And yeah, it would be nice if eventually a spring cleaning could remove some of the mistakes - Enumeration, Date/Calendar, Hashtable, ClassLoader, etc.