Deserialization Vulnerabilities: Explain it Like I’m 5

Insecure deserialization vulnerabilities have come up recently in the news again with the latest exploit against Apache ActiveMQ. If you’ve never heard of this type of vulnerability or want to know more about it, we’ve put together a simple explanation to get started.

Let’s begin with serialization, the process of turning data objects into a flat format. This process takes all of the fields, subfields, sub-subfields, and so on and turns it into a single piece of data that is easier to be transported and processed. Next is deserialization, the process where the receiving application takes the flat format and restores it to the shape of the original data object so it can be interacted with. Many programming languages offer support for this and can be called many things, such as marshalling in Ruby or pickling in Python.

The vulnerability arises when objects are deserialized in an unexpected way, often coming from programming practices not expecting malicious user behavior. If the object has user-controllable data or can be replaced by a different object entirely and the application does not properly handle this, is can result in an exploit. Even with checks, some deserialization attacks do not require the application to complete deserialize the object, so the exploit can happen before checks are implemented. A determined hacker will be able to manipulate serialized objects if no security is put in place before such objects reach the application. Often this will result in a denial of service condition or remote code execution, among other attack possibilities.

Only trusted inputs should be deserialized. This should never include anything that the user has control over. It may be hard to exactly determine where the instances of this attack can occur as applications often have large amounts of library dependencies. These can have a large number of methods and classes that interact with data and the attacker is able to sneak something in. Adding digital signature checks or building custom de-/serialization methods can help prevent these attacks. If you are struggling to identify all the risks in your application infrastructure, Glassportal may be able to help. Schedule a demo with us: demo@glassportal.io