It helps, but does not solve the problem completely.
Firstly user servlets that use getResource or getRealPath
calls will not use the tomcat URL mechanism. JspServlet
in 3.1 is a good example of this.
constraint on /secret/* does not protect servlet
at *.jsp from /SecRet/private.jsp
I don't know if JspServlet has been updated in 3.2 (???) but
most servlets are not under the control of tomcat.
Furthermore, it has been pointed out that case may not
be involved, as NT does 8.3 rewriting.
A security constraint at
/loongdirectoryname/*
will be bypassed with a request like
/loongd~1/private.txt
Also I have been able to access WeB-InF in sites running
catalina, which I thought was only part of 3.2??? So the
fix may not work?
Even if it is fixed in 3.2, this really should be put out as
a tomcat security alert for 3.1. I have been able to
access several public servers not, look at their web.xml
configuration and see their class files.
As PUT, MOVE and DEL can also be protected with security c
onstraints, it may be possible to actually place new content,
code and configuration in some WEB-INF directories on badly
configured servers.
Note that I have also found several servers that say they are ISS 4
that suffer from this problem - I don't know what container is
behind them? Also I have just had a report of apache suffering
from the same problem:
<location "/manual">
AllowOverride None
deny from all
</location>
Does not protect /MaNuAl. So this is not just a servlet issue.
However I think the design of the security constrain mechanism
encourages this problem as it only allows negative constrainst
from a positive default. The other way around is much safer!
So I think that the whole security constraint mechanism needs
to be clarified so that multiple, empty and relaxed constraints
are well specified.
Petr Jiricka wrote:
>
> Does not the following address this issue for Tomcat 3.2 ? (from
> $TOMCAT_HOME/doc/readme)
>
> 6.7 URL's are now case sensitive on all operating systems
>
> As of Tomcat 3.2, URL's are case sensitive for all operating systems,
> including operating systems which have case insensitive file systems, such
> as
> Windows. This represents a change from Tomcat 3.1, where URL's were case
> insensitive on case insensitive OS's. This was done for a number of
> reasons,
> security and portability among them.
>
> Petr
>
> > -----Original Message-----
> > From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 30, 2000 11:21 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Web application security problem on windows
> >
> >
> >
> > 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
> >
> > --
> > 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
> >
>
> -------------------------- eGroups Sponsor -------------------------~-~>
> eGroups eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9698/0/_/9472/_/975675867/
> ---------------------------------------------------------------------_->
>
> For the latest information about Jetty, please see http://jetty.mortbay.
--
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
