security

[Bob Herrmann <bo...@jadn.com>]

Looking into the Tomcat jars, I noticed the package "org.apache.jk"
isn't blocked... so even with the Security Manager running, I think I am
able to get catalina to load "arbitrary classes" like this,

<%
   org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
"someClass" };

   org.apache.jk.apr.TomcatStarter.main(new String[0]);
%>

So, My question is, should we "block" access to package "org.apache.jk"
from webapps?

Cheers,
-bob





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: security

[Bob Herrmann <bo...@jadn.com>]

On Wed, 2002-10-16 at 17:12, Costin Manolache wrote:
> Bob Herrmann wrote:
> 
> > 
> > Looking into the Tomcat jars, I noticed the package "org.apache.jk"
> > isn't blocked... so even with the Security Manager running, I think I am
> > able to get catalina to load "arbitrary classes" like this,
> > 
> > <%
> >    org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
> > "someClass" };
> > 
> >    org.apache.jk.apr.TomcatStarter.main(new String[0]);
> > %>
> > 
> > So, My question is, should we "block" access to package "org.apache.jk"
> > from webapps?
> 
> Bob,
> 
> This won't change the security rules or context in any way. If you 
> are able to create 'someClass', you can call it directly. If
> you call it via TomcatStarter - there is no difference as long
> as no doPriviledged block is reached ( since the security context
> is the intersection of all callers - and this call is originated
> from user code ).

I am a tad fuzzy on this security stuff... but if the "system class
loader" is (or a higher privileged class loader has loaded the
TomcatStarter class), then wont the "Class.forName()" that it does
bypass the possible webapp restriction on class loading... (for example
the webapp classloader restricts accessing org.apache.catalina.*)

> 
> I also think jk is loaded in the server loader - so it shouldn't be
> visible.

My jsp page compiles and seems to invoke the TomcatStarter

> 
> 
> Please, lets wait few more days for commiter list creation and use it 
> for this kind of discussions. If this would be a real exploit, it would be
> much better to have the information public _after_ a fix is commited.

ok.

Cheers,
-bob

> We can forward all the mails to tomcat-dev with a small delay and
> nothing will be lost. If a problem is real, we can fix it first
> and then bounce the message. If not - we can just bounce them
> after we find it is harmless.
> 
> -- 
> Costin
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: security

[Costin Manolache <cm...@yahoo.com>]

Bob Herrmann wrote:

> 
> Looking into the Tomcat jars, I noticed the package "org.apache.jk"
> isn't blocked... so even with the Security Manager running, I think I am
> able to get catalina to load "arbitrary classes" like this,
> 
> <%
>    org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
> "someClass" };
> 
>    org.apache.jk.apr.TomcatStarter.main(new String[0]);
> %>
> 
> So, My question is, should we "block" access to package "org.apache.jk"
> from webapps?

Bob,

This won't change the security rules or context in any way. If you 
are able to create 'someClass', you can call it directly. If
you call it via TomcatStarter - there is no difference as long
as no doPriviledged block is reached ( since the security context
is the intersection of all callers - and this call is originated
from user code ).

I also think jk is loaded in the server loader - so it shouldn't be
visible.


Please, lets wait few more days for commiter list creation and use it 
for this kind of discussions. If this would be a real exploit, it would be
much better to have the information public _after_ a fix is commited.

We can forward all the mails to tomcat-dev with a small delay and
nothing will be lost. If a problem is real, we can fix it first
and then bounce the message. If not - we can just bounce them
after we find it is harmless.

-- 
Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>