I hope this fix is temporary because it disables the serialization of
closures.
I think you can take a look to the way lambdas are
serialized/deserialized in Java
http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html
(see section Serialization)
basically the idea is that when desugaring a closure, the compiler adds
a code
in the script that checks that the closure references the right method and
when doing the deserialization, the closure (or a proxy representing the
closure)
is first validated by the code of the script before being accessible.
cheers,
Rémi
On 07/16/2015 12:02 PM, Cédric Champeau wrote:
*Severity*: Important
*Vendor*: The Apache Software Foundation
*Versions Affected*:
All unsupported versions ranging from 1.7.0 to 2.4.3.
*Impact*
Remote execution of untrusted code, DoS
*Description*
When an application has Groovy on classpath and that it uses standard
Java serialization mechanims to communicate between servers, or to
store local data, it is possible for an attacker to bake a special
serialized object that will execute code directly when deserialized.
All applications which rely on serialization and do not isolate the
code which deserializes objects are subject to this vulnerability.
*Mitigation*
Apache Groovy 2.4.4 is the first and only supported release under the
Apache Software Foundation. It is strongly recommanded that all users
upgrade to this version. If you cannot upgrade or rely on an older,
unsupported version of Groovy, you can apply the following patch on
the MethodClosure class
(src/main/org/codehaus/groovy/runtime/MethodClosure.java):
public class MethodClosure extends Closure {
+ private Object readResolve() {
+ throw new UnsupportedOperationException();
+ }
*Credit*
This vulnerability was discovered by:
cpnrodzc7 working with HP's Zero Day Initiative
*References*
http://groovy-lang.org/security.html
