  Nowadays, an increasing number of applications uses deserialization. This
technique, based on rebuilding the instance of objects from serialized byte
streams, can be dangerous since it can open the application to attacks such as
remote code execution (RCE) if the data to deserialize is originating from an
untrusted source. Deserialization vulnerabilities are so critical that they are
in OWASP's list of top 10 security risks for web applications. This is mainly
caused by faults in the development process of applications and by flaws in
their dependencies, i.e., flaws in the libraries used by these applications. No
previous work has studied deserialization attacks in-depth: How are they
performed? How are weaknesses introduced and patched? And for how long are
vulnerabilities present in the codebase? To yield a deeper understanding of
this important kind of vulnerability, we perform two main analyses: one on
attack gadgets, i.e., exploitable pieces of code, present in Java libraries,
and one on vulnerabilities present in Java applications. For the first
analysis, we conduct an exploratory large-scale study by running 256515
experiments in which we vary the versions of libraries for each of the 19
publicly available exploits. Such attacks rely on a combination of gadgets
present in one or multiple Java libraries. A gadget is a method which is using
objects or fields that can be attacker-controlled. Our goal is to precisely
identify library versions containing gadgets and to understand how gadgets have
been introduced and how they have been patched. We observe that the
modification of one innocent-looking detail in a class -- such as making it
public -- can already introduce a gadget. Furthermore, we noticed that among
the studied libraries, 37.5% are not patched, leaving gadgets available for
future attacks. For the second analysis, we manually analyze 104
deserialization vulnerabilities CVEs to understand how vulnerabilities are
introduced and patched in real-life Java applications. Results indicate that
the vulnerabilities are not always completely patched or that a workaround
solution is proposed. With a workaround solution, applications are still
vulnerable since the code itself is unchanged.

Cryptography and Security;Software Engineering