6622002 breaks JTable's default renderers?

[Tom Hawtin]

On 06/12/2010 17:11, Denis Lila wrote:

> We have this bug report http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=590
> relating to the default rendering of Boolean values in JTables. It was caused because
> we backported http://hg.openjdk.java.net/jdk7/jdk7-gate/jdk/rev/0f510337dadb. I filed
> sun bug 7004655 for it.

There was a regression test failure for that bug which doesn't appear to 
have been ported along with the original fix. I believe the CR is 
6877535, but you wont be able to see that on the Bug Parade.

> The test included with the fix for 6622002 is pretty explicit in that we shouldn't be
> able to reflectively create non public instances of a class, but I think this is wrong.
> In the JTable$BooleanRenderer case, all we're trying to do is instantiate BooleanRenderer
> from JTable. BooleanRenderer is not public, but it is a nested class in JTable, so it and
> all of its members are visible from JTable, which is where we're trying to lazily instantiate
> it. Therefore, I think this is definitely a bug. I don't know a whole lot about security
> in java (which is why I'm not sending a webrev along with this message), but as far as I can
> see, a fix would simply involve looking at the stack trace in the ProxyLazyValue constructors
> to find the class name of the caller. Then, using that, we improve the logic in checkAccess
> to take things like nested classes into account.

That is roughly how reflection access is checked. It is incredibly 
dangerous and makes no sense. Methods that check the immediate caller 
are mention in section 6 of the Java Secure Coding Guidelines[1]. We 
really don't want to start adding to those lists of methods. 
Retrospectively relaxing access checking on existing methods would 
potentially open flaws.

A sensible fix is to stop JTable exploiting the vulnerability. There are 
a variety of ways of doing so.

Tom

[1]http://java.sun.com/security/seccodeguide.html