If you use Jackson Databind library and run a security scanner, you might have received quite a lot of alerts about deserialization vulnerabilities. In the past, a new CVE pop up nearly every month when someone discovered a new deserialization gadget that could be used to exploit an application. Fortunately, the project doesn’t assign CVEs for new deserialization gadgets anymore. It makes sense because an application that uses Jackson libraries is not vulnerable by default. However, if the application uses Jackson libraries in a certain way, it may be in danger.
Below I’ll show how CodeQL can be used to to check whether or not an application is vulnerable to deserialization attacks.
Java RMI uses the default Java deserialization mechanism for passing parameters during remote method invocations. In other words, RMI uses ObjectInputStream that is a well-known unsafe deserialization mechanism. If an attacker can find and send a deserialization gadget to a vulnerable remote method, in the worst case it can result in arbitrary code execution.
I recently wrote a CodeQL query that looks for dangerous remote objects registered in an RMI registry. This post describes the vulnerability and how the query works.
In this blog post, I’ll talk about detecting unsafe Spring Exporters with a CodeQL query. First, I’ll describe the issue that received CVE-2016-1000027. Next, I’ll show what a vulnerable code looks like and how the issue can be mitigated in an application. Then, I’ll describe how the CodeQL query works. In addition, I’ll show a couple of vulnerabilities that have been found by the query.
The Java standard library provides the ObjectInputStream class which offers a convenient way for deserializing Java objects. Unfortunately, this way is not safe by default. Using this class may open the doors for Java deserialization attacks which in the worse case may result in arbitrary code execution.
I recently discovered that Spring Security OAuth2 library may be vulnerable to such an attack. Fortunately, there is one strong pre-requisite for a successful attack which may be difficult to meet for an adversary. Nevertheless, I thought it might be better to make the library a bit safer, and the project maintainers kindly accepted the contribution. Here are the details.
New Jackson 2.10 was released on Sep 26th, 2019. Everyone who uses the library and also scans their applications for known vulnerabilities knows about the problem with endless CVEs that have been reporting against Jackson. Let’s try to understand what makes an application vulnerable and how the new version of Jackson can help to prevent deserialization vulnerabilities.