Can someone briefly explain the problems and how general they are to other serialization interfaces?
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.
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.
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.
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…
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.
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.
Both that VBS, and DOC/XLS, contain some code inside. But users though they are just data files, so they opened these things, running the code.
Also, old MS office files were not limited to embedded VBA. They are OLE compound files, so a specially crafted file can create and run ActiveX objects (often implemented as Win32 DLLs registered under HKEY_CLASSES_ROOT key of the registry) installed on user’s system. This is very similar to the way Java serializer creates and runs objects when desterilizing data received from untrusted source.
Examples: Java Serialization, Python marshal and pickle, Ruby marshal, Perl Data::Dumper.