Hi all,
I think all u guys need to see this mail posted at
[EMAIL PROTECTED],as we jsp users have more to do with
tomcat than others. The reply to this mail from adminstrators at
servlet-interest were quiet unconvincing.
All tomcat 3.1 users are immediately under threat. Pls check other
engines also. There also seems to be a similar problem with apache
e.g.
<location "/manual">
AllowOverride None
Deny from all
</location>
One can access the "/manual" sub-directory by simply changing the
case.
pls confirm it also .
Regards
John Thomas.
***************************************************************************************************************
Posted by
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)2074394045
Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
http://www.mortbay.com AU Phone: +61-(0)2 99772395
""
*************************************************************************************************""
Web applications running on Windows (or other systems with non case
sensitive file systems) can have secure content accessed by
using different case. The problem is a design problem for
security-constraints and an implementation problem for WEB-INF
For example I have been able to access /WeB-iNf/web.xml on several
public servers running tomcat/catalina on NT. The current release
of Jetty3 also is vulnerable and probably most other servlet
containers.
As URLs are case sensitive, the security constraints are bypassed
by the different case request. However, once these requests are
converted to real filenames or file URLs, the JVM is able to
provide a file for them.
The impact of this can be significant, as it allows unauthorized
access
to WEB-INF/web.xml. Furthermore any code in WEB-INF/classes or
WEB-INF/lib may be accessed and decompiled and inspected for other
vulnerabilities.
Also vulnerable are any servlets written using getResource or
getRealPath APIs that pass/use pathInfo. If these servlets are
protected by a security constraint including alpha numeric
characters, then they are vulnerable.
For example, a security constraint of /secret/* will not
protect a JSP like /secret/private.jsp. As a request to
/SeCrEt/private.jsp will correctly bypass the security
constraint, while the JspServlet at *.jsp will be able to find a
matching jsp source file using getRealPath and/or getResource.
Which will be compiled and a result returned. Note that
both the security constraint and the JSP servlet are acting
correctly for their given path specifications.
NB. I have verified that jasper (3.1) is vulnerable to this attack.
A general fix will be difficult to find, as many servlets use
getRealPath and their own file handling. Furthermore, the
real case of a file cannot be determined easily (getCanonicalPath
does not return the actual file's case on at least one popular
JVM (sun JDK1.2.2 on linux accessing a remote NT file system).
Thus a general check for case matching cannot be made.
I am currently of the opinion that design changes are needed in
the security-constraint mechanism to at least allow case
insensitive url-patterns to be used.
A better solution would be to specify the behaviour of multiple
security constraints, plus allow relaxing constraints.
This may even be possible within the current web.dtd?
If the most specific security constraint takes precedent (as it
probably does), then a reasonable solution can be reached by
placing a restrictive constraint on / and then defining less
restrictive constraints on more specific paths. This may be
a valid interpretation of the current specification, but if
so, it needs to be clarified.
Note that protection of the WEB-INF directory is separate
to considerations of user defined security constraints, other
than it probably shares a common implementation. WEB-INF should be
protected from case base access regardless of any action taken on
security constraints.
A final point is that this may show that it may not have
been a good idea to place WEB-INF and all it's content
within the document root. Perhaps an alternate web application
directory layout can be considered with a document root as
a sibling or child rather than a parent of WEB-INF.
eg. if WEB-INF/docroot exists, then it becomes the
document root.
regards
PS. sorry if this has been raised before in these forums, but
my searches could not find anything
************************************************************************************
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
