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
