AccessibleObject.setAccessible() backward compatibility

[Tim Boudreau]

If the implementation of MethodHandle uses setAccessible() (I don't know
its internals), then this Java 0day would qualify:

http://pastebin.com/cUG2ayjh

which I picked apart here:
http://timboudreau.com/blog/The_Java_Security_Exploit_in_(Mostly)_Plain_English/read

-Tim


On Fri, Sep 11, 2015 at 1:44 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 09/11/2015 12:15 PM, Remi Forax wrote:
>
>> There are two changes to setAccessible that make migration to the module
>> universe hard.
>>
>> The first one is that setAccessible() is now declared final which is a
>> binary incompatible change so it breaks Guava two projects of mine.
>>
>> The second change is that now setAccessible() is now CallerSensitive and
>> throw an exception if the AccessibleObject is not visible from the caller
>> class.
>> While this change may improve the security, it's a backward incompatible
>> change is not strictly required to support modules it's more an enhancement
>> of the current security model and i don't think it's a good idea to mix it
>> with the introduction of the module support. More philosophically, every
>> libraries that propose an abstraction that hide underlying dirts provides
>> an escape hatch, the reflection API is one of such hatch of Java the
>> language allowing to bypass the typechecker and the security sandbox.
>> Trying to close the hatch will just make people to open holes in the nearby
>> wall with hacks that are less secure and that may even compromise the
>> integrity of the plateform.
>>
>
> I'm not sure there are real-world cases where the additional accessibility
> rules are actually useful or improve security in any real way.  Maybe we
> need some sample use cases that we can pick apart?
>
> --
> - DML
>



-- 
http://timboudreau.com