In my original announcement I mentioned two other ways to protect Tomcat
from this vulnerability:
A. Tomcat in tandem with HTTP server front-end:
a. If you are using front-end HTTP server you can filter all
requests with the pattern
*/servlet/org.apache.catalina.servlets.DefaultServlet*
b. If you are using mod_jk to connect tomcat to you
front-end server map to Tomcat only the URL's that are part from you
application but not all request. See the usage of JkMount directive.
B. If you are using standalone Tomcat then add protection for this
location in all you application descriptors - web.xml. Simple example:
<security-constraint>
<display-name>Default Servlet</display-name>
<!-- Disable direct alls on the Default Servlet</web-resource-name -->
<web-resource-collection>
<web-resource-name>Disallowed Location</web-resource-name>
<url-pattern>/servlet/org.apache.catalina.servlets.DefaultServlet/*</url-pat
tern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name></role-name>
</auth-constraint>
</security-constraint>
You can try and test any of them on you own risk.
Regards,
Rossen Raykov
> -----Original Message-----
> From: John Trollinger [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 24, 2002 1:33 PM
> To: 'Tomcat Users List'
> Subject: RE: tomcat 4.1.12
>
>
> Map the servlet to a know name using
>
> <servlet-mapping>
> <servlet-name>smimc</servlet-name>
> <url-pattern>/<webapp>/smimc</url-pattern>
> </servlet-mapping>
>
> > -----Original Message-----
> > From: William Lee [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 24, 2002 1:07 PM
> > To: Tomcat Users List
> > Subject: Re: tomcat 4.1.12
> >
> >
> > Tim Funk wrote:
> > > There was a security flaw in 4.1.11 and earlier that so that
> > > /servlet/*
> > > could be used for bad things. The flaw was fixed in the
> > invoker servlet
> > > for the "obvious" issues but it still leaves the door open
> > for people to
> > > do other bad things if people aren't careful.
> > >
> > > In $CATALINA_HOME/conf/web.xml - look for the invoker servlet and
> > > uncomment it to turn that functionality back on. My guess
> > is it is now
> > > commented out by default (which is a good practice to have).
> > >
> > > Personally - I hate the concept of /servlet/* being able
> to invoke a
> > > class. It may make development easier - but then you run
> > into subtle
> > > security goofs.
> > >
> > > -Tim
> > >
> >
> > Please excuse my ignorance, what's the preferred way to
> > invoke a servlet
> > class file then?
> >
> > I have a servlet named smimc that I defined a web.xml inside the
> > smimc/WEB-INF/ directory:
> >
> > ...
> > <servlet>
> > <servlet-name>
> > smimc
> > </servlet-name>
> > <servlet-class>
> > org.apache.turbine.Turbine
> > </servlet-class>
> > ...
> >
> > I used to be able to invoke it with the path /smimc/servlet/smimc
> >
> > However, this doesn't seem to work anymore with the invoker
> > turned off.
> > I can turn the lines in tomcat's web.xml back on but that risks
> > security (?). So what's the proper way for this to work then?
> >
> > Will
> >
> >
> > --
> > William Lee (Will) | Sendmail Inc.
> > Email: [EMAIL PROTECTED] | http://www.sendmail.com
> > Tel: (510) 594-5505 |
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-user-> [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
