proxy an interface and call a default method

[Peter Levart]

On 05/27/2016 01:40 PM, Remi Forax wrote:
> I don't see the issue if the lookup object represent the proxy class itself restricted to only access to public methods.
>
> Rémi

I think there could be security issues. For example, let there be an 
interface like:

public interface Resource {
     InputStream openStream() throws IOException;

     default byte[] getContent() throws IOException {
         try (InputStream is = openStream()) {
             return is.readAllBytes();
         }
     }
}

Then there might be an implementation that overrides both methods, like:

public class SecuredResource implements Resource {

     @CallerSensitive
     @Override
     public InputStream openStream() throws IOException {
         checkPermission(Reflection.getCallerClass());
         return openStreamImpl();
     }

     @CallerSensitive
     @Override
     public byte[] getContent() throws IOException {
         checkPermission(Reflection.getCallerClass());
         try (InputStream is = openStreamImpl()) {
             return is.readAllBytes();
         }
     }

     private InputStream openStreamImpl() throws IOException { ...
     ...
}


If Proxy API allowed access to a MH(invokespecial Resource::getContent), 
then one could abuse such MH to circumvent access check in an instance 
of SecuredResource by making it appear it was invoked from the Resource 
class.

I think that bytecode verifier does not allow such things and 
SecuredResource can be considered perfectly safe in this respect.

The solution could be for Proxy API to provide a MH that was already 
bound to the Proxy instance. Such pre-bound MH could not be abused then.

Regards, Peter

>
> ----- Mail original -----
>> De: "Peter Levart" <peter.levart at gmail.com>
>> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>, "jochen Theodorou" <blackdrag at gmx.org>
>> Envoyé: Vendredi 27 Mai 2016 12:50:34
>> Objet: Re: proxy an interface and call a default method
>>
>> Hi,
>>
>> I think the main problem here is that by providing the InvocationHandler
>> with a Lookup that could provide "invokespecial" MHs for the proxy
>> interface(s) could be abused. Anyone can create a Proxy for any public
>> interface and supply its own InvocationHandler which could be used to
>> "steal" such Lookup object.
>>
>> There would have to be a way to restrict calling interface "super"
>> methods from InvocationHandler *INSTANCES* that are bound to particular
>> Proxy instances.
>>
>> Hm...
>>
>> Regards, Peter
>>
>> On 05/26/2016 08:20 AM, Jochen Theodorou wrote:
>>> Hi all,
>>>
>>> I am looking for a solution to the following problem... I have an
>>> interface and an object that is supposed to serve as implementation,
>>> but does not implement the interface. n methods of the interface will
>>> be redirected to the object, but in case of default methods I would
>>> like to have the implementation provided by the interface. I am
>>> looking especially for a solution without me generating classes at
>>> runtime by hand.
>>>
>>> Now there are several problems... I seem not to be able to invoke a
>>> default method by reflection. By MethodHandles I did something like this:
>>>
>>>> MethodHandles.Lookup.class.getDeclaredConstructor(Class.class,
>>>> int.class).
>>>>        newInstance(interfaceClass, MethodHandles.Lookup.PRIVATE).
>>>>        unreflectSpecial(method, interfaceClass).
>>>>        bindTo(receiver);
>>> where receiver is a dynamic proxy, method the Method of the default
>>> method, interfaceClass the Class of the interface with the default
>>> method.
>>>
>>> But I am calling a private constructor here, which is bad, plus the
>>> above procedure does no longer work on JDK9.
>>>
>>> So what am I supposed to do? change from a proxy to runtime generated
>>> classes and hope the best for classloaders and modules not getting in
>>> my way?
>>>
>>> bye Jochen
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>