Tomcat 3.2

[Costin Manolache <co...@eng.sun.com>]

Hi,

I'm reviewing the diffs between the main trunk and the 3.2 branch.

So far most of the changes are the logger - I guess Sam ( and everyone
else ) should decide if this should go into 3.2 or not, and if so
 to make the integration. The diff has 110 pages so far.

Besides logging, we also have:
- URL decoding
- .bat script changes

I would also like to know what is the status - do we have any -1
on releasing 3.2 and what are the problems to be addressed,
etc.

I plan to start doing some major changes in class loader area,
start removing all the deprecated code that is not used, and start
a serious review of the core for security and clean core/facade
separation, but it can wait until the merge is done.

Costin

Re: Tomcat 3.2

[Danno Ferrin <sh...@earthlink.net>]

    After reading the bugtraq a little closer I realized that is is not
snoop.jsp but the snoop servlet run from an extension mapping in the jsp
directory.  Would just modifying the build to remove SnoopServlet.class
from the examples war (but leaving the java file) work?  It still will
provide ugly failures but it's the most painless and certainly quickest
fix. Leaving the source still allows for development use.  Unless there
is objection I intend on modifying the build.xml tomorrow to do this for
the dist target.  This is the last outstanding bugtraq bug that I know
of.

please reply with +'s and -'s

--Danno

cmanolache@yahoo.com wrote:
> 
> >
> > That leaves the snoop.jsp bug and the admin context insecurity.  The
> > admin.war could just be distributed in a different location and we put
> 
> I think I resovled admin context - even if it is loaded, the admin must
> edit server.xml and turn "trusted" to "true" ( the default is false ).
> 
> Without this flag the admin can't access tomcat internals and can't do
> anything wrong ( it's a bit ugly - since it can't get the internal Context
> it will display a NPE ).
> 
> I also added a security constraint requiring "admin" role to access the
> admin app.  The server admin must edit tomcat-users and add a user/pass
> that have admin role in order for admin app to work.
> 
> I think it's enough for now, probably we need to document this ( in the
> FAQ or in admin index.html )
> 
> I don't remember what was the problem with snoop.jsp - but regarding stack
> traces there are many other servlet engines showing stack traces on error.
> We do need a solution, but probably tomcat 3.3 is the best place to
> implement it.
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: Tomcat 3.2

[cm...@yahoo.com]

> 
> That leaves the snoop.jsp bug and the admin context insecurity.  The
> admin.war could just be distributed in a different location and we put

I think I resovled admin context - even if it is loaded, the admin must
edit server.xml and turn "trusted" to "true" ( the default is false ).

Without this flag the admin can't access tomcat internals and can't do
anything wrong ( it's a bit ugly - since it can't get the internal Context
it will display a NPE ).

I also added a security constraint requiring "admin" role to access the
admin app.  The server admin must edit tomcat-users and add a user/pass
that have admin role in order for admin app to work.

I think it's enough for now, probably we need to document this ( in the
FAQ or in admin index.html )


I don't remember what was the problem with snoop.jsp - but regarding stack
traces there are many other servlet engines showing stack traces on error. 
We do need a solution, but probably tomcat 3.3 is the best place to
implement it.

Costin 

Re: Tomcat 3.2

[Danno Ferrin <sh...@earthlink.net>]

The only thing is that I think that there are some bugtraq bugs that we
need a story for in the Tomcat 3.2 release.  

I just submitted a tomcat_32 line only fix for the JSP not found Too
Much Info bug that eliminates too much info to the response stream.  If
it's good enough maybe we could put it into the main-line but I think we
should put the insecure_TMI flag somewhere more global and limit stack
traces based on this flag as well if this solution gets a promotion to
the main line.

That leaves the snoop.jsp bug and the admin context insecurity.  The
admin.war could just be distributed in a different location and we put
in the docs instructions on how to install it ("cd $TOMCAT_HOME;mv
admin.war webapps" or for win32 ("cd %TOMCAT_HOME% && move admin.war
webapps\webapps.war").  snoop.jsp could just be removed or edited so
that the offending sections (context attributes and server info) are
JSP-commented out (<%-- --%>) so that if the person installing it really
wants to see that info they can get it.  

Perhaps a better solution may be a modification of Jon Stevens'
solution: make a tomcat-dist distribution which is presented as having
no outstanding security issues (but both tomcat and jasper) and a
tomcat-devel distribution which includes all the demos and tools that
are inherently insecure (such as showing the file location of unfound
JSP pages, the snoop servlet and snoop jsp page, and the adman installed
by default) but very useful for development.  If anyone were to minus
one this idea I wouldn't be offended, but it might be good to re-thread
it so we can localize the discussion.

But until we get a unified story and perhaps a solution on those two
bugtraq bugs I would be -0 to making 3.2 final.  If I had more time to
commit to addressing these issues I would be minus one but I just don't
have the time right now.  All of the other factors for a release are
plus one otherwise.

--Danno

Costin Manolache wrote:
> 
> Hi,
> 
> I'm reviewing the diffs between the main trunk and the 3.2 branch.
> 
> So far most of the changes are the logger - I guess Sam ( and everyone
> else ) should decide if this should go into 3.2 or not, and if so
>  to make the integration. The diff has 110 pages so far.
> 
> Besides logging, we also have:
> - URL decoding
> - .bat script changes
> 
> I would also like to know what is the status - do we have any -1
> on releasing 3.2 and what are the problems to be addressed,
> etc.
> 
> I plan to start doing some major changes in class loader area,
> start removing all the deprecated code that is not used, and start
> a serious review of the core for security and clean core/facade
> separation, but it can wait until the merge is done.
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org