> Your solution looks good too, and yes, one would need > to be able to catalog all their /servlet/ uses, make > servlet mapping entries in the web.xml, then change > all > code that uses those servlets to use the mapped name > instead.
Well what I was suggesting was to map them to the same name that they're already being invoked with. So you wouldn't have to change the code that uses them. Assuming that my suggestion actually works the way I think it should. :-) It looks like you're right: the fix for this issue is incomplete. It assumes that you were using the full class name of the servlet, and not the servlet name. So http://www.mycompany.com/myapp/servlet/org.apache.catalina.servlets.Defa ultServlet/some.jsp is no longer vulnerable, but http://www.mycompany.com/myapp/servlet/default/some.jsp is! On the other hand, the thing you posted to jguru has the opposite problem. You'll need to add a second servlet mapping to the source disclosure blocker for /servlet/org.apache.catalina.servlets.DefaultServlet/* -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 > -----Original Message----- > From: Brad Plies [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 25, 2002 7:26 PM > To: Tomcat Users List > Subject: RE: Jsp source disclosure patch for legacy type 1 > architectures > > > Thanks for the reply Tim, > > I had downloaded and installed Apache Tomcat 4.1.12 > (link on the news page), and tested it using the same > server & webapp config, and the vulnerability still > existed. Maybe I shouldn't have recycled the server > configs, but it still got through. > > Your solution looks good too, and yes, one would need > to be able to catalog all their /servlet/ uses, make > servlet mapping entries in the web.xml, then change > all > code that uses those servlets to use the mapped name > instead. > > I guess the solution I offered is independent of any > webapp, and works on the server config level. Thanks > for the idea, I think I will try yours because it is > more explicit & elegant on the webapp level. > > Thanks again! > > --- Tim Moore <[EMAIL PROTECTED]> wrote: > > They also changed the InvokerServlet so that it > > can't be used to invoke > > other built-in servlets (including the > > DefaultServlet). So even if you > > uncomment the invoker servlet, you still won't be > > vulnerable to this > > specific exploit. > > > > There might be other ways in which your site is > > vulnerable to invoker > > servlet exploits, however. It's best to try to > > disable it if possible. > > > > One thing that might work (though I haven't tried > > it) is to explicitly > > map your servlets to the names they would be invoked > > as. For example, > > if you have a servlet com.mycompany.MyServlet that > > you were invoking as: > > > > > http://www.mycompany.com/myapp/servlet/com.mycompany.MyServlet > > > > you should be able to add this to your myapp's > > web.xml: > > > > <servlet> > > <servlet-name>MyServlet</servlet-name> > > > > > <servlet-class>com.mycompany.MyServlet</servlet-class> > > </servlet> > > > > ... > > > > <servlet-mapping> > > <servlet-name>MyServlet</servlet-name> > > > > > <url-pattern>/servlet/com.mycompany.MyServlet</url-pattern> > > </servlet-mapping> > > > > and repeat that for all of the other servlets you > > use. I think this > > would do the trick and you could then disable the > > invoker servlet. But, > > as I said, I haven't actually tried this, and > > obviously you would need > > to be able to catalog all of the servlets that your application was > > using. > > -- > > Tim Moore / Blackboard Inc. / Software Engineer > > 1899 L Street, NW / 5th Floor / Washington, DC 20036 > > Phone 202-463-4860 ext. 258 / Fax 202-463-4863 > > > > > > > -----Original Message----- > > > From: Brad Plies [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, September 25, 2002 6:53 PM > > > To: [EMAIL PROTECTED] > > > Subject: Jsp source disclosure patch for legacy > > type 1 architectures > > > > > > > > > I am not sure about the process of offering > > patches & > > > workarounds, but anyway, according to > > > http://jakarta.apache.org/site/news.html#0924.1 > > the latest > > > patch is actually only a disabling of the Invoker > > servlet. > > > However some people with old code that who are > > relying on the > > > Invoker servlet and cannot disable it w/o breaking > > their site > > > are still exposed. > > > > > > I have posted my own custom hack to solve this > > > problem, and it can be found here > > > 1004251=> 1004251 > > > > > > Someone > > > please gently correct me with any mistakes > > > I > > > have made, I'm just trying to be helpful here. > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
