commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [logging] tech.xml - child-first classloading not considered harmful
Date Fri, 29 Apr 2005 16:27:47 GMT
A key issue is your assertion that a "correctly written" class loader
will always delegate loads of java.* and javax.* classes.  When
considering security, your concern is not about correctly written
things, it is about deliberately malicious things.  A maliciously
written class loader could indeed impersonate system classes -- the
quoted example of potentially replacing the SecurityManager instance
for the entire JVM (and thereby subverting all security manager
checks) is real.


On 4/29/05, 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?
> Notes:
> (1) it *is* a security issue for users to be able to define their own
> ClassLoaders, because java *trusts* a ClassLoader to truly indicate the
> source-location, signatures and permissions of each loaded class.
> (2) Properly written child-first classloaders never load any classes in
> the "java.*" or "javax.*" domains anyway - they always delegate for
> these domains.
> (3) Even if a child-first classloader did accidentally load something
> such as a hacked
>   (a) it wouldn't be able to pass it to any system library (ie
>      impersonate the real class) because the receiver (loaded via the
>      bootclassloader) would have resolved at startup time to
>      SecurityManager@bootclassloader, which is a completely different
>     class to SecurityManager@somechildclassloader. Attempting to pass
>     the latter to something expecting the former will generate an
>     exception.
>   (b) as long as the classloader has associated the correct permissions
>     with the class when it was loaded (ie the perms associated with the
>    webapp source location) then the class can't do any secure operations
>    directly. And if the classloader has misrepresented the security
>    perms on the class, then security is wide-open anyway regardless of
>    whether the loaded class is called SecurityManager or MachineTrasher.
> Assuming no-one can show my arguments here to be false, then the
> question remains: what is the purpose of parent-first classloading? I've
> been trying to find an answer to this for a while....
> Comments?
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message