Replacement of sun.reflect.Reflection#getCallerClass

[Remi Forax]

On 09/03/2013 10:17 AM, Jochen Theodorou wrote:
> Am 03.09.2013 05:04, schrieb Mandy Chung:
>> Hi Nick,
>>
>> Thanks for the patch.
>>
>> JEP 176 [1] describes the caller-sensitive method and the need for a
>> mechanical checking of caller-sensitive methods.  Also Peter Levart in
>> [2] explained the change in MethodHandles.Lookup related to @CS.  I
>> assume you understand the rationale behind and the potential security
>> issues.  In general defining caller-sensitive API is discouraged.
>
> The problem is, and the JDK itself shows that, that you sometimes 
> cannot avoid caller-sensitive API. I thought that was clear by now. I 
> am not the patch author, so understanding the potential security 
> issues was not addressed to me, but I would like to understand them. 
> So far I did hear only that if you have the Class object, you can do 
> something, you normally cannot do. I would be interested in an 
> example. Java security is really complicated to understand, and this 
> would help to shed some light on the issue for others. Also I am 
> wondering, if the Class object is a no-go, then how about class name 
> and class loader? For Groovy we need the loader, but since we need to 
> filter stack elements ourselves too, we also need the class names. A 
> Class-object provides both, but I am sure almost all usages out there 
> could work with the name and the loader only and if needed loading the 
> class from the loader, with permissions set accordingly. Not sure how 
> it is with internal class names here of course. AnonymousClassLoader 
> would probably cause trouble here, but afaik that did not make it out 
> of JSR292.
>
> A different way to solve the issue was suggested as using an 
> annotation to define frames which are not looked up by getCallerClass. 
> But it did not get any interest. So I am really curious how you want 
> to solve this.

I think there are two different things, first, there are several methods 
in the JDK that allows operations or not (like calling a method by 
example) based on the caller class. So if you can impersonate the caller 
class, you can do privilege escalation.
The fact that the method that does a security check based on the caller 
class (or the caller stack trace) has to be tagged using @CallerSensitive
for the method handle API is an implementation detail. The current 
implementation of the method handle API invocation in Hotspot may used 
intermediary stack frame between the method call do a 
methodHandle.invoke/invokeEaxct and the actual called method. If the 
actual method do a security check using the caller class, it may see an 
intermediary method and not the original caller method so if you are not 
able to detect the caller sensitive method, you can use the method 
handle API to do privilege escalation. That's why in the JDK, methods 
that are caller sensitive are marked with the annotation 
@CallerSensitive. Again, this is an implementation issue specific to the 
way the method handles are implemented, so that's why @CallerSensitive 
is defined in package sun.invoke and not in a public API.

Now, correct me if I'm wrong, for Groovy, you need to get the groovy 
caller method, (it can be a Java method because you can implement a 
callback in Groovy and send it to a Java code) so you should not use 
getCallerClass which should be reserved for security checks but another 
method that will return the caller method (or caller methods) that will 
filter out and the intermediary methods due to the method handle 
implementation and the intermediary methods due to the Groovy runtime 
(those can be marked with an annotations).

So there is a need for an API to get the caller classes which is not 
getCallerClass (or any methods in a package sun.*) that will hide you 
the method handle API impementation and allow you choose to filter 
caller methods using a user defined API.

[...]

> bye Jochen
>

cheers,
Rémi