You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Cédric Champeau <cc...@apache.org> on 2015/07/16 12:02:21 UTC
[CVE-2015-3253] Apache Groovy Zero-Day Vulnerability Disclosure
*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
Re: [CVE-2015-3253] Apache Groovy Zero-Day Vulnerability Disclosure
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 16.07.2015 14:42, schrieb Remi Forax:
> 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.
yes, I was looking at this before already and I was not sure how to put
this into the existing MethodClosure class without breaking things. So
my resolution was, that with the old class we cannot do this without
breaking the serialization format. Which is why I agreed to this
short-term change, to then discuss a better long-term change now.
The Vulnerability basically uses several mechanisms in a chain, that you
cannot use like that in Java with lambdas. First there is a
MethodClosure with a valid target method. Then there is a Proxy, which
is serializable. And then of course there is a deprecated (only kpt o
backwards compatibility), but still working Java class, which imho
behaves incorrectly (but surely arguable) on deserializaton, which is
used as entry point.
Frankly I am not 100% convinced that the Java way is safe, but it is
surely more difficult. You need a deserialize method to support you. A
functional interface and the accessible method, all with mostly fitting
signatures. But given those I am almost sure I could produce a similar
exploit. Groovy just makes it much more easy by being much more flexible
for the signatures, allowing more methods to be accessible and being
able to use a proxy in combination with a method reference without
requiring a functional interface.
And of course there is a way to make the Groovy exploit not work anymore
by utilizing the java security manager.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
Re: [CVE-2015-3253] Apache Groovy Zero-Day Vulnerability Disclosure
Posted by Cédric Champeau <ce...@gmail.com>.
There is a flag which enables it again. It is not recommended to
activate it. We didn't find any better way to do this yet, it's more
than just verifying that the target method is what you want, it's that
deserialization triggers execution of code because of an implicit
coercion...
2015-07-16 14:42 GMT+02:00 Remi Forax <fo...@univ-mlv.fr>:
> 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
>
>
Re: [CVE-2015-3253] Apache Groovy Zero-Day Vulnerability Disclosure
Posted by Remi Forax <fo...@univ-mlv.fr>.
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