> > Can anyone show any real security issues resulting from child-first > > loading? > > i would suggest that the operative word here is real. it is very > possible for sun to have chosen to recommend parent-first as the default > for the reason given whilst at the same time the threat not being > particularly credible in real life. >
This sounds reasonable to me. It would be nice to have something definitive, however. I think it's an interesting topic and I've be following it on this list. So far, all the security risks Simon has referenced (and questioned) don't seem to go much beyond hand-waving so I agree with him they are dubious. A test case demonstrating some of these alleged security risks would be helpful; I can't put my head around them without more detail and context. Could be that these risks only affect 1% or real-world apps under a specific scenario. Even if it's 0.01% or entirely theoretical, a test case would be useful to even understand what the risk really is supposed to be. As an aside, isn't "child-first" really a misnomer and it's more like "parent-last"? Assuming the parent is at the top of the hierarchy, child-first implies (to me), that the heirarchy is walked downwardly from the parent, not upwardly from the bottom. Mike Colbert --- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Fri, 2005-04-29 at 23:02 +1200, Simon Kitching wrote: > > Hi All, > > > > The following paragraph is from the "xdocs/tech.xml" document: > > > > <quote> > > Parent-first loading has been the standard mechanism in the JDK > > class loader, at least since Java 1.2 introduced hierarchical > > classloaders. > > > > The primary reason for this is safety -- parent-first > > makes it impossible for malicious code to trick the JVM into > > replacing a core class (say, <code>java.security.SecurityManager</code>) > > with a class of the same name loaded from a child classloader. > > </quote> > > > > I believe this to be incorrect. I don't believe that such substitution > > leads to any kind of security issue at all, and think this paragraph > > should be removed from the document. > > > > Can anyone show any real security issues resulting from child-first > > loading? > > i would suggest that the operative word here is real. it is very > possible for sun to have chosen to recommend parent-first as the default > for the reason given whilst at the same time the threat not being > particularly credible in real life. > > a malicious classloader could perform all manner of nasty tricks. in > this case, it doesn't really matter whether this classloader pretends to > be parent or child first. not sure how credible a threat this is. not > sure how an attacker could manage to insert a malicious classloader. > (maybe other people with more knowledge would like to jump in here...) > > consider (instead) a badly written classloader. the threat to the system > from a badly written parent-first classloader is much less than that > from a badly written child-first classloader. bugs in the selection of > which classes must be delegated (for security reasons) may allow > malicious code to replace crucial security classes. > > whether this is a credible threat in real life is another matter. > opinions? > > - robert > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
