On Wed, 3 Feb 2021 17:20:40 GMT, Mandy Chung <[email protected]> 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
