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.
Since around .NET 5 the raw binary serializer (BinaryFormatter) throws danger warnings at compile time, generally doesn't work cross-platform, and most standard analysis configs upgrade those to compile errors. The documentation is full of similar danger warnings. It mostly remains for a backwards compatibility commitment, and most of the original use cases for BinaryFormatter have been generally all replaced with Span<T>, Memory<T>, and smarter "Unsafe" [0] Marshallers.
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.
Nice! But, doesn't negate my intent: warning that .net isn't immune to the binary serialization issues.
I haven't had much of a chance to work with non-framework/mono unfortunately. So, good to see they made the issues explicit. Though, I chuckle at the idea of companies upgrading such to errors via config- but thats an iceberg of "the street is looking better than doing more coding."
In general a lot has changed for the better since 4.x and mono.
> Though, I chuckle at the idea of companies upgrading such to errors via config-
Depends on the company's code quality standards, of course. A lot of companies in my experience let tools like SonarQube drive towards very strict "linter" configs.
I also almost failed to mention it (but did in a quick edit), but I also think that the cross-platform compatibility issues in this case also especially drive companies to avoid BinaryFormatter "naturally". The .NET team made a series of correct decisions that while they couldn't break backward compatibility (all the way back to the OG .NET Framework 1.0) they could keep cross-machine compatibility broken (it was always broken, unlike Java's Serializable, BinaryFormatter was always primarily for FFI and local single machine use, which anyone trying to use it for distributed serialization almost always found out the hard way eventually) and even expand it to be "more obviously broken". One of the core abilities in .NET 5+ is to be able to build/test locally in Windows or macOS and then push to, say, Docker containers on a Linux server. BinaryFormatter absolutely does not work in such scenarios and makes a loud racket if you try. Additionally, there are even now subtle incompatibilities between say type of Windows machine.
Getting bit by that is easy, and will also naturally cause companies to expedite moving warnings to errors in their configs.
On the carrot side, too, System.Text.Json is now out of the box in every .NET allowing for very easy (and quick/performant) JSON serialization. Not having to install a third/second-party library for a secure, standards-based serializer is a big deal and helps remove a lot of the reasons people would accidentally rely on BinaryFormatter. (Similar to the old days when Python only provided pickling out of the box and it took maybe too long for a json library to move to first party standard library inclusion. It's great that both languages have solved that.)
The idea that the session ViewState is a static encryption shared across all installs (unless I misread that)... speaks poorly of the software product in general.
Bugdoors like this will be the norm in a few years from now. Why spend the money and time and effort needed to pass something like chatcontr0l when you can just bugcontrol everything
> We can’t see a path to exploit this without a valid private key. On paper, that should kill the bug dead.
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.
That would be wild if true. Basically this is a object serialization vulnerability exploited in the wild right now, but it only deserializes signed objects, so the author is speculating if their private key leaked, or even better, if the company signed the malicous payload themselves lol
So would the signed 'object' contain code? Or is it just data? And even if it is code, does deserializing mean execution? I guess it could mean execution at some other stage in the process.
What is the end-goal of this... would it be data exfiltration vs ransomware.
You've created a class which an attacker can plug in any object which implements `SerializableFunction` into `bar`. That includes externally created functions!
It often results in remote code/command execution, its data that de-serializes into java objects. But during the instantiation or sometimes deconstruction of objects, code can be executed. Popular tool for java: https://github.com/frohoff/ysoserial
Ah, my most hated enemy. Java Serialization.
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.
Nothing will ever be funnier than the quote from that Java language designer guy, "Java Serialization is a full employment act for security engineers"
.Net has similar issues.
Since around .NET 5 the raw binary serializer (BinaryFormatter) throws danger warnings at compile time, generally doesn't work cross-platform, and most standard analysis configs upgrade those to compile errors. The documentation is full of similar danger warnings. It mostly remains for a backwards compatibility commitment, and most of the original use cases for BinaryFormatter have been generally all replaced with Span<T>, Memory<T>, and smarter "Unsafe" [0] Marshallers.
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.
Nice! But, doesn't negate my intent: warning that .net isn't immune to the binary serialization issues.
I haven't had much of a chance to work with non-framework/mono unfortunately. So, good to see they made the issues explicit. Though, I chuckle at the idea of companies upgrading such to errors via config- but thats an iceberg of "the street is looking better than doing more coding."
In general a lot has changed for the better since 4.x and mono.
> Though, I chuckle at the idea of companies upgrading such to errors via config-
Depends on the company's code quality standards, of course. A lot of companies in my experience let tools like SonarQube drive towards very strict "linter" configs.
I also almost failed to mention it (but did in a quick edit), but I also think that the cross-platform compatibility issues in this case also especially drive companies to avoid BinaryFormatter "naturally". The .NET team made a series of correct decisions that while they couldn't break backward compatibility (all the way back to the OG .NET Framework 1.0) they could keep cross-machine compatibility broken (it was always broken, unlike Java's Serializable, BinaryFormatter was always primarily for FFI and local single machine use, which anyone trying to use it for distributed serialization almost always found out the hard way eventually) and even expand it to be "more obviously broken". One of the core abilities in .NET 5+ is to be able to build/test locally in Windows or macOS and then push to, say, Docker containers on a Linux server. BinaryFormatter absolutely does not work in such scenarios and makes a loud racket if you try. Additionally, there are even now subtle incompatibilities between say type of Windows machine.
Getting bit by that is easy, and will also naturally cause companies to expedite moving warnings to errors in their configs.
On the carrot side, too, System.Text.Json is now out of the box in every .NET allowing for very easy (and quick/performant) JSON serialization. Not having to install a third/second-party library for a secure, standards-based serializer is a big deal and helps remove a lot of the reasons people would accidentally rely on BinaryFormatter. (Similar to the old days when Python only provided pickling out of the box and it took maybe too long for a json library to move to first party standard library inclusion. It's great that both languages have solved that.)
Yea, .Net has massively improved. I just had an awful employer who burned me out- possibly for good.
I don't think I need to say more than: 98% of the code base was ASP.net backed by .Net FW 1.1, the rest was VB6.
The idea that the session ViewState is a static encryption shared across all installs (unless I misread that)... speaks poorly of the software product in general.
Bugdoors like this will be the norm in a few years from now. Why spend the money and time and effort needed to pass something like chatcontr0l when you can just bugcontrol everything
Archive [1]
[1] - https://archive.is/OsSe0
> We can’t see a path to exploit this without a valid private key. On paper, that should kill the bug dead.
The juicy theory bit:
That would be wild if true. Basically this is a object serialization vulnerability exploited in the wild right now, but it only deserializes signed objects, so the author is speculating if their private key leaked, or even better, if the company signed the malicous payload themselves lolSo would the signed 'object' contain code? Or is it just data? And even if it is code, does deserializing mean execution? I guess it could mean execution at some other stage in the process.
What is the end-goal of this... would it be data exfiltration vs ransomware.
Java object serialization can be super dangerous as it just works on any class that implements serializable.
That means if the shape of your object is something like
You've created a class which an attacker can plug in any object which implements `SerializableFunction` into `bar`. That includes externally created functions!Here's an article detailing exactly how that works: https://www.baeldung.com/java-serialize-lambda
> What is the end-goal of this... would it be data exfiltration vs ransomware.
The end-goal is to gain complete access to the system - the outcome (data theft or ransomware) is customers choice
It often results in remote code/command execution, its data that de-serializes into java objects. But during the instantiation or sometimes deconstruction of objects, code can be executed. Popular tool for java: https://github.com/frohoff/ysoserial
Usually sites let you read a sentance or two before asking you to subscribe with a "popup"... this one doesn't even wait that long.