6622002 breaks JTable's default renderers?
tom.hawtin at oracle.com
Tue Dec 7 08:09:17 PST 2010
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. 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.
More information about the security-dev