3 ms·

Can someone briefly explain the problems and how general they are to other serialization interfaces?

blattimwind 8y ago
Many runtimes include object serialization capabilities, which allow serialization of essentially arbitrary object structures with little code. Unpacking that kind of structure always means that you're constructing object instances of potentially any object you can construct, which generally means you can run arbitrary code. Examples: Java Serialization, Python marshal and pickle, Ruby marshal, Perl Data::Dumper.
- jeffdavis 8y ago
  So the problems don't apply to, say, rust because rust doesn't run arbitrary initialization when building structures?
  - curun1r 8y ago
    This is a key point. The problem is significantly worse because of Java's "everything is an object" philosophy. In languages where data is just data and not a combination of data and behavior, you don't get this kind of problem.
    - pron 8y ago
      You also don't get this behavior if you restrict the scope of serialization. The problem here was that Java wanted to make virtually any object potentially serializable. This required all sorts of deep hacks that circumvent various language guarantees and open the door to vulnerabilities (as well as encumber new features, as serialization could interact with anything). A new serialization mechanism would be restricted to classes for which serialization makes sense, basically classes that, as you say, represent data rather than data with complex behavior.
  - steveklabnik 8y ago
    It's not that exactly. For more: https://www.reddit.com/r/rust/comments/8mjait/is_serialization_considered_a_security_risk/dzo0u5g/ https://www.reddit.com/r/rust/comments/8mjait/is_serializati...
foob 8y ago
Here's an article which explains in detail how pickles/serialization work in Python, and how pickles can be constructed to evaluate malicious code when they are deserialized. That's specifically about Python, but the same issue exists in many other languages. [1] - https://intoli.com/blog/dangerous-pickles/ https://intoli.com/blog/dangerous-pickles/
mbfg 8y ago
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).
- chii 8y ago
  > 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.
  - MBCook 8y ago
    From the article it sounds like you’ll only be able to use the replacement on Java data classes, sort of like JSON structures or C structs. 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…
  - dwaite 8y ago
    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.
Const-me 8y ago
> and how general they are to other serialization interfaces? 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. (1) https://en.wikipedia.org/wiki/ILOVEYOU https://en.wikipedia.org/wiki/ILOVEYOU (2) https://en.wikipedia.org/wiki/Melissa_(computer_virus) https://en.wikipedia.org/wiki/Melissa_(computer_virus)
- dfox 8y ago
  Except that (1) was completely normal executable program (albeit in not well-known "format", which windows has many) and was not in any way executed automatically (and has nothing to with Java). And (2) is VBA macro virus which again has nothing to do with Java.
  - Const-me 8y ago
    The comment I replied to specifically asked about other serialization interfaces. 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.

Many runtimes include object serialization capabilities, which allow serialization of essentially arbitrary object structures with little code. Unpacking that kind of structure always means that you're constructing object instances of potentially any object you can construct, which generally means you can run arbitrary code. Examples: Java Serialization, Python marshal and pickle, Ruby marshal, Perl Data::Dumper.

jeffdavis 8y ago
So the problems don't apply to, say, rust because rust doesn't run arbitrary initialization when building structures?
- curun1r 8y ago
  This is a key point. The problem is significantly worse because of Java's "everything is an object" philosophy. In languages where data is just data and not a combination of data and behavior, you don't get this kind of problem.
  - pron 8y ago
    You also don't get this behavior if you restrict the scope of serialization. The problem here was that Java wanted to make virtually any object potentially serializable. This required all sorts of deep hacks that circumvent various language guarantees and open the door to vulnerabilities (as well as encumber new features, as serialization could interact with anything). A new serialization mechanism would be restricted to classes for which serialization makes sense, basically classes that, as you say, represent data rather than data with complex behavior.
- steveklabnik 8y ago
  It's not that exactly. For more: https://www.reddit.com/r/rust/comments/8mjait/is_serialization_considered_a_security_risk/dzo0u5g/ https://www.reddit.com/r/rust/comments/8mjait/is_serializati...

foob 8y ago

Here's an article which explains in detail how pickles/serialization work in Python, and how pickles can be constructed to evaluate malicious code when they are deserialized. That's specifically about Python, but the same issue exists in many other languages. [1] - https://intoli.com/blog/dangerous-pickles/ https://intoli.com/blog/dangerous-pickles/

mbfg 8y ago

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).

chii 8y ago
> 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.
- MBCook 8y ago
  From the article it sounds like you’ll only be able to use the replacement on Java data classes, sort of like JSON structures or C structs. 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…
- dwaite 8y ago
  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.

Const-me 8y ago

> and how general they are to other serialization interfaces? 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. (1) https://en.wikipedia.org/wiki/ILOVEYOU https://en.wikipedia.org/wiki/ILOVEYOU (2) https://en.wikipedia.org/wiki/Melissa_(computer_virus) https://en.wikipedia.org/wiki/Melissa_(computer_virus)

dfox 8y ago
Except that (1) was completely normal executable program (albeit in not well-known "format", which windows has many) and was not in any way executed automatically (and has nothing to with Java). And (2) is VBA macro virus which again has nothing to do with Java.
- Const-me 8y ago
  The comment I replied to specifically asked about other serialization interfaces. 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.