You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by cm...@yahoo.com on 2000/08/14 21:22:58 UTC
Security: printStackTrace :-)
If you remember the goal is to provide real security to tomcat, and
that requires a lot of work and review before we can trust that a web
application can do no harm in the same way an applet can't ( or
shouldn't).
One big problem was the recycling - there is a fix and I'll implement it
asap. ( the problem: a servlet can hold a reference to the
HttpServletRequest and read the request from other unrelated webapps).
A second problem:
In Logger we do a printStackTrace for the original exception ( can be
ServletException ) and also on the "rootCause" exception ( using
getRootCause). This is a very useful information and feature, but it may
open a wrong door.
A web app may define a new Exception and redefine
printStackTrace() method. The method do display the exception is invoked
from ContextManager - so runs with webapp.jar priviledges. That mean an
un-trusted app might get more rights that it should.
We need to check if this is correct ( i.e. if this happens or the security
manager will run as untrusted if it detect untrusted code in the call
path, even if the original caller is trusted ) and if so to disable it.
Costin
( with a hacker hat )
Re: Security: printStackTrace :-)
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
> In Logger we do a printStackTrace for the original exception ( can be
> ServletException ) and also on the "rootCause" exception ( using
> getRootCause). This is a very useful information and feature, but it may
> open a wrong door.
If we disable printStackTrace, we should do so via a flag in
server.xml. Make the secure option default the default, but put a
comment describing the tradeoff. I think we already talked about
disabling stack traces on error pages, but it seems like nobody did
anything about it, since I still see stack traces occasionally.
But hmm, if there is a problem like you describe, it applies both to
printStackTrace onto a web page *and* into a log file... Hope you're
just being paranoid :-)
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/
Re: Security: printStackTrace :-)
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
cmanolache@yahoo.com wrote:
>
> If you remember the goal is to provide real security to tomcat, and
> that requires a lot of work and review before we can trust that a web
> application can do no harm in the same way an applet can't ( or
> shouldn't).
>
> One big problem was the recycling - there is a fix and I'll implement it
> asap. ( the problem: a servlet can hold a reference to the
> HttpServletRequest and read the request from other unrelated webapps).
>
> A second problem:
>
> In Logger we do a printStackTrace for the original exception ( can be
> ServletException ) and also on the "rootCause" exception ( using
> getRootCause). This is a very useful information and feature, but it may
> open a wrong door.
>
> A web app may define a new Exception and redefine
> printStackTrace() method. The method do display the exception is invoked
> from ContextManager - so runs with webapp.jar priviledges. That mean an
> un-trusted app might get more rights that it should.
>
> We need to check if this is correct ( i.e. if this happens or the security
> manager will run as untrusted if it detect untrusted code in the call
> path, even if the original caller is trusted ) and if so to disable it.
>
I don't think this will be a problem, of course we should test to verify
that. Your webapp defined Exception would have been assigned the
ProtectionDomain of the webapp, not that of the ContextManager, so any
time methods in the webapp defined Exception is run, it will be restricted
by whatever policies were defined for the webapp.
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Security: printStackTrace :-)
Posted by Costin Manolache <co...@eng.sun.com>.
>
> how about System.exit() called inside a servlet ? That blows away
> everything i think...last time i checked at least. it killed the tomcat
> instance completely...
> -Ys-
> yhs@mimic.onmesourcecorp.com
You need to enable the policy-based security ( and use JDK1.2 )!
You shouldn't be able to do anything from a servlet except
read to webapps files, write to workdir and anything else that
is specified in the tomcat.policy file.
( I know this still needs work and documentations )
Costin
Re: Security: printStackTrace :-)
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
On Mon, 14 Aug 2000 cmanolache@yahoo.com wrote:
> If you remember the goal is to provide real security to tomcat, and
> that requires a lot of work and review before we can trust that a web
> application can do no harm in the same way an applet can't ( or
> shouldn't).
><SNIP>
> We need to check if this is correct ( i.e. if this happens or the security
> manager will run as untrusted if it detect untrusted code in the call
> path, even if the original caller is trusted ) and if so to disable it.
>
> Costin
> ( with a hacker hat )
how about System.exit() called inside a servlet ? That blows away
everything i think...last time i checked at least. it killed the tomcat
instance completely...
-Ys-
yhs@mimic.onmesourcecorp.com