Re: Have I got this right?
It's not quite that simple. Usually deserialization doesn't in itself execute anything, and usually the application that's deserializing data from an unsafe source is doing something like this:
1. Deserialize a data stream into an object graph.
2. If that succeeds (it's a well-formed graph and all the necessary classes are available on the classpath), make sure it's an instance of what you were expecting.
3. Do stuff with deserialized objects.
The "Marshalling Pickles" presentation from AppSecCali 2015 that started this particular thread of inquiry1 showed some of the Really Dumb mistakes, like using a serialized object as an HTTP cookie and putting things like the user ID in it.
But that was just a warm-up. The real meat of the presentation was an exploit that, in simplified form, did get code executed during deserialization, i.e. in step 1, before the application could get to step 2. Let's see if I can get this right from memory: apache-commons includes a "transformer" class that, among other things, would reflect on some other objects and execute methods in them, based on data in a map - as part of being deserialized. And another class in commons could be used to put arbitrary data into that map. So you serialize an object graph that includes the transformer and the other class and something of your own that implements Runnable, and during deserialization the transformer will invoke Run on your payload object.
That's why statements like "it is not a flaw in Java itself, but instead a flaw in a widely used library" (Ullrich, quoted in the article) are dangerously misleading. Yes, the transformer implementation in commons is a Bad Thing. But pointing at libraries is just playing whack-a-mole. The core issue is deserializing untrusted data. And as I noted in another post above, there's a lot of that going around.
A custom deserializer that whitelists object classes prior to deserialization helps. Whether it helps enough to be worth it is another question.
Can you do the same thing with, say, .NET WCF? I don't know that you can with the stock framework binary serializer, because a quick look suggests it doesn't provide the same sort of hooks for classes to play silly buggers during their own deserialization. But XmlSerializer, for example, can be implemented using custom code (by implementing IXmlSerializable), and someone could certainly write an exploitable vulnerability into that. Then someone would have to create a WCF binding that used the vulnerable serialization method. So not likely to be a widespread problem, but there may well be some instances out there.
1We've known for a long time that serialization led to some interesting attack vectors, of course. The MP presentation revealed some new exploit paths, among other things.