3 ms·

The twitter thread says something about serialized objects containing malicious code. I didn't realize Java had that. Can someone explain in more detail?

freeqaz 5y ago
There are some more details in this post we wrote up earlier[0]. Feel free to throw me any questions (I'm a security engineer). 0: https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/
chii 5y ago
Java has the ability to serialize a class, send it over the network, and deserialize it back into a usable class. This mechanism is quite flexible, and allows the class itself to control some aspect of it's own serialization (such as code to run post-serialization, as a form of initialiation, somewhat similar to a constructor). So if you load a class from an unknown source (such as this exploit's example), you are basically allowing RCE.
- tcoff91 5y ago
  This is such a massive footgun wow...
  - chii 5y ago
    it's not any different from eval() tbh - the onus is on the programmer to not trust input. The problem is when libraries do unexpected things, like the log4j RCE.
- immibis 5y ago
  Note that the class itself is not serialized. Only the instance of the class is serialized. The class itself is looked up by name in the running program. This is still a footgun because you can try to deserialize classes that weren't meant to be deserialized in this context, but it's a way smaller footgun than being able to just load arbitrary code into the program.
usrusr 5y ago
Java deserialization won't directly pull executable code from incoming bytes, but without deliberate countermeasures the deserialization runtime will happily try to create new instances of any class visible in the classpath configuration of the VM if the incoming bytes ask nicely. And many of the classes that might be present come with static code that will run once before the first class instance is created, setting up global state and the like. Others come with custom deserialization routines and when both appear together and interact with each other you get a surprisingly big space for possibile vulnerabilities to hide in. If memory serves me right, in the early days of Java deserializion vulnerabilities they usually involved some native code that was started by that mechanism. There used to be quite a lot of that, inherited from the days when Sun tried to create a multimedia powerhouse running on the inefficient JVM of the day
- throwaway81523 5y ago
  Ah thanks, that sounds like pickling in Python. It took forever for them to understand that unpickling untrested data was a security hole.
  - formerly_proven 5y ago
    2.2 tried to create a "safe for unpickling" way (https://docs.python.org/2.2/lib/pickle-sec.html https://docs.python.org/2.2/lib/pickle-sec.html) which unsurprisingly failed (https://www.python.org/dev/peps/pep-0307/ https://www.python.org/dev/peps/pep-0307/ 2003) > This feature gives a false sense of security: nobody has ever done the necessary, extensive, code audit to prove that unpickling untrusted pickles cannot invoke unwanted code, and in fact bugs in the Python 2.2 pickle.py module make it easy to circumvent these security measures. > We firmly believe that, on the Internet, it is better to know that you are using an insecure protocol than to trust a protocol to be secure whose implementation hasn't been thoroughly checked. A few years ago, I think around 2016, there was a series of RCEs in many Java apps because they used the Java equivalent of pickle with the Java equivalent of "make pickle safe", which did not work.
    - immibis 5y ago
nostoc 5y ago
Java and deserialization vulnerabilities are one of the most iconic duos of infosec.

freeqaz 5y ago

There are some more details in this post we wrote up earlier[0]. Feel free to throw me any questions (I'm a security engineer). 0: https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/

chii 5y ago

Java has the ability to serialize a class, send it over the network, and deserialize it back into a usable class. This mechanism is quite flexible, and allows the class itself to control some aspect of it's own serialization (such as code to run post-serialization, as a form of initialiation, somewhat similar to a constructor). So if you load a class from an unknown source (such as this exploit's example), you are basically allowing RCE.

tcoff91 5y ago
This is such a massive footgun wow...
- chii 5y ago
  it's not any different from eval() tbh - the onus is on the programmer to not trust input. The problem is when libraries do unexpected things, like the log4j RCE.
immibis 5y ago
Note that the class itself is not serialized. Only the instance of the class is serialized. The class itself is looked up by name in the running program. This is still a footgun because you can try to deserialize classes that weren't meant to be deserialized in this context, but it's a way smaller footgun than being able to just load arbitrary code into the program.

usrusr 5y ago

Java deserialization won't directly pull executable code from incoming bytes, but without deliberate countermeasures the deserialization runtime will happily try to create new instances of any class visible in the classpath configuration of the VM if the incoming bytes ask nicely. And many of the classes that might be present come with static code that will run once before the first class instance is created, setting up global state and the like. Others come with custom deserialization routines and when both appear together and interact with each other you get a surprisingly big space for possibile vulnerabilities to hide in. If memory serves me right, in the early days of Java deserializion vulnerabilities they usually involved some native code that was started by that mechanism. There used to be quite a lot of that, inherited from the days when Sun tried to create a multimedia powerhouse running on the inefficient JVM of the day

throwaway81523 5y ago
Ah thanks, that sounds like pickling in Python. It took forever for them to understand that unpickling untrested data was a security hole.
- formerly_proven 5y ago
  2.2 tried to create a "safe for unpickling" way (https://docs.python.org/2.2/lib/pickle-sec.html https://docs.python.org/2.2/lib/pickle-sec.html) which unsurprisingly failed (https://www.python.org/dev/peps/pep-0307/ https://www.python.org/dev/peps/pep-0307/ 2003) > This feature gives a false sense of security: nobody has ever done the necessary, extensive, code audit to prove that unpickling untrusted pickles cannot invoke unwanted code, and in fact bugs in the Python 2.2 pickle.py module make it easy to circumvent these security measures. > We firmly believe that, on the Internet, it is better to know that you are using an insecure protocol than to trust a protocol to be secure whose implementation hasn't been thoroughly checked. A few years ago, I think around 2016, there was a series of RCEs in many Java apps because they used the Java equivalent of pickle with the Java equivalent of "make pickle safe", which did not work.
  - immibis 5y ago

nostoc 5y ago

Java and deserialization vulnerabilities are one of the most iconic duos of infosec.