RFR: 8013527: calling MethodHandles.lookup on itself leads to errors

[Mandy Chung]

On Wed, 3 Feb 2021 17:20:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1205:
>> 
>>> 1203:             Class<?> invokerClass = new Lookup(targetClass)
>>> 1204:                     .makeHiddenClassDefiner(name, INJECTED_INVOKER_TEMPLATE, Set.of(NESTMATE))
>>> 1205:                     .defineClass(true, targetClass);
>> 
>> Using the target class directly could lead to some unintended problems.
>> 
>> An attacker can define it's own hidden class as nestmate and with a name ending in `$$InjectedInvoker`.  
>> This allows the attacker to "teleport" into a nestmate with full privileges.  
>> An attacker could then access `MethodHandles.classData`.
>> 
>> Suggested remedy: Create a holder that is only visible to `java.lang.invoke`:
>> 
>> /* package-private */ static class OriginalCallerHolder {
>>     final Class<?> originalCaller;
>>     OriginalCallerHolder(Class<?> originalCaller) {
>>         this.originalCaller = originalCaller;
>>     }
>> }
>> 
>> As this type is only visible inside `java.lang.invoke`, it can't be created without hacking into `java.lang.invoke`, at which point all bets are off anyway.
>> 
>> (A previous commit was even more dangerous, as you can force `jlr.Proxy` to inject a class into your package with a `null`-PD)
>
> Only `Lookup` with the original access can access `MethodHandles.classData`.   A hidden class `HC$$InjectedInvoker/0x1234` can access private members of another class `C` in the same nest but not `C`'s class data.
> 
> I don't follow which previous commit you refer to more dangerous.  Please elaborate.   I don't see any security concern with class data.

Last night, I had a second thought that the fix for these two JBS issues does not need the class data.  It's more for a future use.  I plan to revise it and drop class data in this fix anyway.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2367