Apache Groovy Deserialization: A Cunning Exploit Chain to Bypass a Patch

The original bug, discovered by cpnrodzc7 and given the identifier ZDI-15-365/CVE-2015-3253, is a bug in the Groovy programming language. Groovy is implemented in Java and defines various new serializable Java classes. One of these classes, MethodClosure, is particularly problematic from a security standpoint. A MethodClosure instance holds a reference to an object and a method name. When a caller invokes doCall on the MethodClosure, the MethodClosure calls the named method on the specified object. By placing a serialized MethodClosure into a stream, an attacker can cause quite a dangerous object to be formed upon deserialization. Furthermore, it is not difficult to include additional crafted objects in the stream so that the doCall method will be invoked automatically, producing remote code execution.

It follows that it is quite hazardous for MethodClosure to be a serializable class. Even if an application has no intention of passing serialized MethodClosure instances, any attacker who is positioned to insert a serialized message can specify a MethodClosure in the stream, which will be dutifully recreated into a live MethodClosure object by the deserialization mechanism. Logically, the only remedy was to change the implementation of MethodClosure so that it is no longer a serializable type. At this point, the Groovy developers were in a pickle. Changing MethodClosure to be non-serializable would involve modifying the class hierarchy and could be too drastic a change for some existing code. They chose to take a middle path by defining a new static field, MethodClosure.ALLOW_RESOLVE. Provided it is kept in its default state of false, any attempt to deserialize a MethodClosure object will result in an exception throw:

        • The hazardous MethodClosure is wrapped in a KRBError. When the
        MethodClosure throws an UnsupportedOperationException, KRBError
        catches it and instead throws an IOException.
        • The KRBError is wrapped in a BeanContextChildSupport.
        BeanContextChildSupport contains code to handle an IOException and does
        not throw any further exception. Instead, it continues deserializing additional
        child objects.
        • Further on within the same BeanContextChildSupport, there is a serialized
        AnnotationInvocationHandler. At deserialization time, this object invokes the
        MethodClosure, resulting in remote code execution. Somewhat surprisingly, even
        though the readResolve method shown above does not complete successfully, the
        deserialized MethodClosure remains available to be referenced via the handle that
        was assigned to it by the deserialization infrastructure.

The use of AnnotationInvocationHandler to produce automated effects at deserialization time is already well known from the ysoserial Java deserialization payload project.

To defend against the new attack, the developers of Groovy patched MethodClosure once more. This time, they introduced a custom readObject method for MethodClosure, so that by default MethodClosure refuses to initialize its fields from a serialized stream:

As before, an attacker might still be able to wrap the object and suppress the exception, thereby obtaining a deserialized MethodClosure. However, the resulting MethodClosure object is harmless because its fields have not been initialized to contain the attacker’s data.

Curiously, the way the readObject method shown above is written, it throws an exception unconditionally. This breaks any legitimate uses of serialization of MethodClosure. Yet the code has remained that way for almost a year. That suggests that there are in fact no legitimate uses for serialization of MethodClosure.

The technique the researcher used for this patch bypass highlights the treacherous nature of deserialization vulnerabilities. The Java deserialization mechanism will create an object of any type that the input stream specifies, provided it is a serializable (or externalizable) type that can be found in the CLASSPATH. Control flow during deserialization proceeds according to the code found within the specified type. This gives an attacker an unusual amount of freedom. Sometimes even an exception throw will be insufficient to stop an exploit chain from achieving remote code execution. When accepting data that may come from an untrusted source, it is recommended to completely avoid general-purpose deserialization mechanisms.