The juicy theory bit:
The vendor accidentally signed evil. Imagine this:
When you activate your GoAnywhere product, your installation generates a serialized license request.
It’s sent to the vendor’s license server (my.goanywhere.com)
If someone slipped a malicious object inside that request and the vendor blindly signed it, attackers would now have a perfectly valid signed payload that works everywhere.
What is the end-goal of this... would it be data exfiltration vs ransomware.
That means if the shape of your object is something like
class Foo implements Serializable {
SerializableFunction bar;
void doBar() {
bar.apply();
}
}
Here's an article detailing exactly how that works: https://www.baeldung.com/java-serialize-lambda
The end-goal is to gain complete access to the system - the outcome (data theft or ransomware) is customers choice
I know that some JDK devs will argue that it's one thing that made Java popular. And I'm sure they are right. But man oh man if it's not one of the biggest footguns in the current JDK. It also constantly gets in the way of Java language development. They had to figure out, for example, "How do I serialize a lambda"? Which should really tell you just how ridiculous this thing is.
If there's one breaking change to the JDK that I'd welcome, it's the removal of Java serialization. But that will never happen because WAY too many companies depend on it.
I'm not sure I'd call the situation similar.
[0] Unsafe in terms of doing memory access that can result in danger, but still far more safe than BinaryFormatter sledgehammers.
[1] - https://archive.is/OsSe0