groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject MethodClosure deserialization problem
Date Sat, 01 Oct 2016 07:55:11 GMT
hi all,

as you guys may remember we added

> private Object readResolve() {
>   if (ALLOW_RESOLVE) {
>     return this;
>   }
>   throw new UnsupportedOperationException();
> }

to prevent proper deserialization of a MethodClosure in case we don't 
want to allow it (which is the default). Now it seems that this approach 
is not enough. I have found several articles stating that it is possible 
to bypass readResolve. In this case you would still have access to the 
fully deserialized object. Thus I suggest we do the following:

> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
{
>   if (ALLOW_RESOLVE) {
>     stream.defaultReadObject();
>   } else {
>     stream.readUTF(); // read method and forget it
>   }
> }

this is very similar to the readResolve implementation of course. So we 
would still fail deserialization, only much earlier. We would still read 
the String for the method, but we would make sure it will not be assigned.

So if malicious code manage to go around readResolve, it would still be 
left with a MethodClosure in which method is null, thus any try to 
invoke a method will fail with a NullpointException.

Afaik this solution would be compatible to earlier versions of Groovy.

What do you guys think?

bye Jochen

Mime
View raw message