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 this happens before the host application regains control of the serialization, and realizes that the objects it's deserializing is not what it expects to be sent. So there have been a bunch of problems where classes no one expected to be used in serialization to be exploited because it's really simple for a class to marked serializable thru inheritance (be it class or interface).
> 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.
The security hole is in the design of java serialization. Any class marked serializable (in your code, your included libraries, or the JVM itself) is a potential security vulnerability as soon as you use this feature. Mark estimated that over half of JRE/JDK vulnerabilities have been due to Serialization.
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.
> Any class marked serializable (in [...] included libraries [...])
This is the big one: as soon as you deserialize incoming data, any library on the classpath becomes a potential source of remote-callable snippets. And when a vulnerability resides in a library, exploits will tend to be compatible across applications, which makes them far more likely to actually hit you than any custom weaknesses.
Programmers should be more careful but then again footguns exist (or in this case legcannons). You shouldn't trust any 3rd party data before validation but how do you validate it if you can't even deserialize it to see what it contains? It's silly.
I can see how it's potentially a problem, but I still don't understand where the vulnerability occurs. The static initializers will be run before the data (which the attacker controls) is inserted into those instances. Yet the attacker has to be able to somehow "execute" code via the data he sends.
There has to be a few specific classes that are common, and that have methods that the attacker can expect will be run (such as toString conversion, comparison etc), where the attacker can control the data used.
E.g. if he knows that serializing a certain collection type containing Font objects will use some platform native code that reads the font data, he can then pass a corrupt font in and fool the deserializer into an out of bounds read. Or something like that. I vaguely remember hearing about one of these attacks and I can't find it. It would be interesting to hear about some real world attacks.
