You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Carman <ja...@carmanconsulting.com> on 2005/05/04 22:41:11 UTC
RE: [logging] tech.xml - child-first classloading not consideredharmful
If a security manager was in place to begin with, which it would be in an
environment which you would want to secure, it probably wouldn't allow
applications to create their own classloaders anyway (the ClassLoader class'
constructor checks to see whether you have that privilege). A reasonable
SecurityManager wouldn't allow itself to be replaced, so a "malicious" one
wouldn't be able to let an application "break out of its sandbox." If there
isn't a SecurityManager installed, there IS no sandbox.
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Wednesday, May 04, 2005 4:39 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] tech.xml - child-first classloading not
consideredharmful
On Wed, 2005-05-04 at 13:03 -0700, Mike Colbert wrote:
> > in the case of a parent-first classloader, the buggy implementation
> > would not be exposed since the call would be delegated to the system
> > classloader. in the case of a child-first classloader, a buggy
> > implementation may try to define SecurityManager itself and this bug
> > exploited.
>
> This would mean an attacker would have to take advantage of a bug in a
> class loader which allows them to load a malicious SecurityManager in
> such a way that it would be shared by all applications. I can kind of
> see how parent-first delegation would mitigate this, but one would
> think that with appropriate levels of class loader isolation in place
> the delegation order becomes a non-issue. Maybe the bug has something
> to do with broken isolation.
i was thinking that a malicious SecurityManager implementation might allow
an application to break out of it's sandbox but i'm not an expert and this
is really just speculation on my part. i don't think that this kind of
attack is any sort of realistic threat. this would be a good time for craig
to jump in...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] tech.xml - child-first classloading notconsideredharmful
Posted by James Carman <ja...@carmanconsulting.com>.
What sort of "bug" in the classloader would you be looking to exploit which
would allow you to install a malicious SecurityManager?
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Wednesday, May 04, 2005 5:33 PM
To: Jakarta Commons Developers List
Subject: RE: [logging] tech.xml - child-first classloading
notconsideredharmful
the setup i had in mind was a container with a buggy classloader. the
security manager would allow classloaders to be created by the container but
try to prevent access to certain files. the malicious web application code
would be crafted to exploit the bug in the container classloader to allow a
malicious SecurityManager to be loaded which would then allow those file to
be read.
- robert
On Wed, 2005-05-04 at 16:41 -0400, James Carman wrote:
> If a security manager was in place to begin with, which it would be in
> an environment which you would want to secure, it probably wouldn't
> allow applications to create their own classloaders anyway (the
> ClassLoader class' constructor checks to see whether you have that
> privilege). A reasonable SecurityManager wouldn't allow itself to be
> replaced, so a "malicious" one wouldn't be able to let an application
> "break out of its sandbox." If there isn't a SecurityManager
> installed, there IS no sandbox.
>
> -----Original Message-----
> From: robert burrell donkin
> [mailto:robertburrelldonkin@blueyonder.co.uk]
> Sent: Wednesday, May 04, 2005 4:39 PM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] tech.xml - child-first classloading not
> consideredharmful
>
>
> On Wed, 2005-05-04 at 13:03 -0700, Mike Colbert wrote:
> > > in the case of a parent-first classloader, the buggy
> > > implementation
> > > would not be exposed since the call would be delegated to the system
> > > classloader. in the case of a child-first classloader, a buggy
> > > implementation may try to define SecurityManager itself and this bug
> > > exploited.
> >
> > This would mean an attacker would have to take advantage of a bug in
> > a
> > class loader which allows them to load a malicious SecurityManager in
> > such a way that it would be shared by all applications. I can kind of
> > see how parent-first delegation would mitigate this, but one would
> > think that with appropriate levels of class loader isolation in place
> > the delegation order becomes a non-issue. Maybe the bug has something
> > to do with broken isolation.
>
> i was thinking that a malicious SecurityManager implementation might
> allow an application to break out of it's sandbox but i'm not an
> expert and this is really just speculation on my part. i don't think
> that this kind of attack is any sort of realistic threat. this would
> be a good time for craig to jump in...
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] tech.xml - child-first classloading not
consideredharmful
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
the setup i had in mind was a container with a buggy classloader. the
security manager would allow classloaders to be created by the container
but try to prevent access to certain files. the malicious web
application code would be crafted to exploit the bug in the container
classloader to allow a malicious SecurityManager to be loaded which
would then allow those file to be read.
- robert
On Wed, 2005-05-04 at 16:41 -0400, James Carman wrote:
> If a security manager was in place to begin with, which it would be in an
> environment which you would want to secure, it probably wouldn't allow
> applications to create their own classloaders anyway (the ClassLoader class'
> constructor checks to see whether you have that privilege). A reasonable
> SecurityManager wouldn't allow itself to be replaced, so a "malicious" one
> wouldn't be able to let an application "break out of its sandbox." If there
> isn't a SecurityManager installed, there IS no sandbox.
>
> -----Original Message-----
> From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
> Sent: Wednesday, May 04, 2005 4:39 PM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] tech.xml - child-first classloading not
> consideredharmful
>
>
> On Wed, 2005-05-04 at 13:03 -0700, Mike Colbert wrote:
> > > in the case of a parent-first classloader, the buggy implementation
> > > would not be exposed since the call would be delegated to the system
> > > classloader. in the case of a child-first classloader, a buggy
> > > implementation may try to define SecurityManager itself and this bug
> > > exploited.
> >
> > This would mean an attacker would have to take advantage of a bug in a
> > class loader which allows them to load a malicious SecurityManager in
> > such a way that it would be shared by all applications. I can kind of
> > see how parent-first delegation would mitigate this, but one would
> > think that with appropriate levels of class loader isolation in place
> > the delegation order becomes a non-issue. Maybe the bug has something
> > to do with broken isolation.
>
> i was thinking that a malicious SecurityManager implementation might allow
> an application to break out of it's sandbox but i'm not an expert and this
> is really just speculation on my part. i don't think that this kind of
> attack is any sort of realistic threat. this would be a good time for craig
> to jump in...
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org