Jackson-Databind - A Story of Blacklisting Java Deserialization Gadgets
In June 2017, an unsafe deserialization vulnerability was discovered in the Jackson-Databind module (CVE-2017-7525) and was patched by creating a blacklist that doesn’t accept certein dangerous Java classes.
The Jackson-Databind module developers created a function named checkIllegalTypes and the only class that was blacklisted was TemplatesImpl which is part of the com.sun.org.apache.xalan package.
Figure 1: The checkIllegalTypes function as it was first written in the BeanDeserializerFactory.java file
An hour passed, and the blacklist was updated to contain more dangerous classes.
Figure 2: More dangerous classes were added to the blacklist.
In December 2017 CVE-2017-17485 was allocated for this exact same vulnerability because it was found that the blacklist didn’t contain dangerous classes from the Spring framework.
After a while another bypass on the blacklist is discovered, now being tracked as CVE-2017-15095.
This is probably not the last change being made on this blacklist because new dangerous classes and gadget chains (Several classes that when combined may lead to Remote Code Execution) are discovered from time to time by security researchers.
Mitigation with ASM
The Jackson-Databind developers are in a rush after new dangerous Java classes that may lead to remote code execution once deserialized and we keep on updating ASM with those Java deserialization gadgets.
As opposed to the Jackson-Databind developers we have additional mitigation layers to rely on, such as Java Server Side Code Injection signatures that detects operating system command execution attempts, for example by using Java's Runtime and ProcessBuilder classes (Signature ids 200003437,200003438,200003439, 200004174) and specific operating system command execution signatures.
Today, a new ASM security update was released to cover additional Java deserialization gadgets discovered recently: