[Cryptography] Simpler programs?

[Jerry Leichter]

On Apr 19, 2014, at 11:11 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
>> I think this is simplistic. Also, Java doesn't really do a good job
>> because of reflection.
> 
> When I last looked closely -- Java 1.3 -- reflection couldn't access private variables. Have they changed that? (I always worry about people adding new features that break the security invariants I am depending on.)
Reflection does indeed allow you to access private variables.  And it even allows you to modify final variables - a feature that gives you a great way to elicit very unpredictable behavior, since the compiler is allowed to assume that the value of final variables doesn't change, so it can in-line the values rather than refer to them through the variable itself.  In both cases, you find the appropriate Field object and then make a call on it that overrides access protections.  In effect, you create a "root" access path to the underlying field that ignores all the access protections that Java implements.  (The field itself is unchanged - unmodified Field objects pointing to it continue to be restricted in their access.)  I haven't had reason to look at the mechanics involved, but I'm pretty sure similar ways to disable the access protections exist for methods and even whole classes.

Also, when you create what passes for a closure in Java - pre-8; I haven't looked at how they've changed it - the only variable values you are allowed to capture are those of final variables, since, again, the "can't change".  What your code will actually see if you use reflection to change the final is an interesting question in head-up-your-ass philosophy.

All of this and more can, of course, also be done through JNI.  I suspect it could also be done by simply gen'ing up your own byte codes to do the access.  (The implementation of Field that I looked at essentially does just that, in fact.)

If you run under a security manager, it can forbid access to private variables and modifications of final ones - but very little code runs under a non-trivial security manager.  (I'm not sure a security manager has fine-grained control over a native (JNI) function, but it can forbid you from loading such functions.)
                                                        -- Jerry