commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] tech.xml - child-first classloading not considered harmful
Date Sun, 01 May 2005 10:28:16 GMT
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></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.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message